An old Macintosh IIci 25Mhz running Apache under NetBSD

Looking at what they're actually doing, basically a few postgres or solr requests, file serving and generating a some web pages...the data for one of our larger deployments barely breaks 1 GB when dumped out of the databases (It doesn't handle more than 100 users at a time)...it should be running cleanly off of a $699 mid-range all-in-one desktop from Costco and have enough headroom for 5,000 more users.

Yet somehow between all the framework, JVM and various other nonsense, there's murmers about moving that system to a more web-scale infrastructure because of all the performance issues we're seeing. Everytime somebody uploads some content to the server 4 of the VMs peg out their cores for several seconds. As I look around in engineering meetings at all the fresh young engineers working on this stuff, nobody seems to think this is a problem.

On the client side the problem is even worse, constrained to the 1990s era performance we're stuck with inside of browsers.

Machines capable of crunching billions of calculations per second, and putting tens of billions of bytes into main memory are brought to their knees dragging and dropping a half-dozen items in a GUI (something my Commodore 64 could actually handle) or running two programs at once, something my Amiga 500 could do.

It's bad and it makes me feel bad. I think growing up when computers were basically terrible has broken me to where things that young engineers think is cool and amazing I'm finding more and more disappointing...it's not that old computers were great, it's that modern computers aren't but they should be.

The future is now, and it kind of sucks.

I don't have the time right now, but I'd be interested if you could whip up a quick simple profile like I did above for various generic Java collections like Map<T,T> and HashMap<T,T> and observe the time and memory consumption for each. I'd guess that the various Hash-like collections in Java will display a similar memory consumption to Perl's.

And a regular old int[] consumes a little over 12MB.

        int [] a = new int[1000000];
        for(int i=0;i<1000000;i++){a[i] = i;}

        Integer [] a = new Integer[1000000];
        for(int i=0;i<1000000;i++){a[i] = i;}

        ArrayList<Integer> a = new ArrayList();
        for(int i=0;i<1000000;i++){ a.add(i); }

        HashMap<Integer,Integer> a = new HashMap();
        for(int i=0;i<1000000;i++){ a.put(i,i); }

- Java ints are 32-bit or 4-bytes. Theoretically then, An array of a million ints is just 41,000,000 or 4,000,000 bytes or just under 4MB. As we can see in my test, 4MB + the size of the JVM running is just about 12MB, or pretty much what's expected.

- An array of a million Integers is actually an array of 64-bit pointers pointing to a 32-bit int, with some other overhead. I've read that an Integer object consumes about 16-bytes total. So a million of those is 15.6MB + 8.5MB = 24.1MB. The actual memory consumption is 42MB, so I'm off by about half, I'm not sure where exactly, but there's probably some kind of extra references to something I'm missing or some kind of JVM house cleaning I'm not thinking about.

- An ArrayList appears to be a nice abstraction on an Array (O(1) adds, get, etc.) It probably has some logic to do the Perl thing and just has some logic to build bigger arrays as more stuff is added. So there's probably some kind of internal penalty when they're exceeded.

But at any rate, I wouldn't expect the memory consumption to be all that different from an array of Integers. And the test shows it to actually be a little tiny bit less at 35MB.

- Now we come to a HashMap. A HashMap is basically a list of key->value pairs. This means that for an entry in the HashMap we need something like (I'm probably wrong in the specific details, but this is a useful thought experiment)

key (8-bytes for pointer to 16-byte Integer) + 8-byte pointer to the value = 32-bytes

value (8-byte pointer to a 16-byte Integer)

So a k->v pair is 56bytes.

1 million of those is about 55MB + 8.5MB = 63.5MB.

BUT, hashes don't consume space linearly as they grow. Many hash function will double the size of the hash once it passes some consumption metric, maybe 50%.

Thus we have potentially 1,000,000 completely empty HashMap entries. Which look like this.

empty key (8-byte pointer to NULL)

value (8-byte pointer to NULL)

or 16-bytes doing nothing in particular 1,000,000 empty entries (50% of the total hash size) ~ 16MB

for a total of 63.5MB + 16MB = 79.5MB. Our actual is 77MB so we're within spitting distance.

So if you consider that Perl's version of this test is 35MB for the Array version, which is on the order of what Java was providing we're pretty good. While the Perl Hash version took up 216MB vs. 77MB -- which is not too surprising as Perl's dynamic typing objects take up lots of memory under the hood.