Comments on: Optimizing Feature Extraction

By: uClassify blog » More memory or smaller memories?

uClassify blog » More memory or smaller memories? — Sun, 16 Oct 2011 09:36:31 +0000

[...] A similar optimization for Java is described on the LingPipe blog. [...]

By: Jon

Jon — Sat, 18 Oct 2008 23:58:41 +0000

Thanks for the good explaination!

By: lingpipe

lingpipe — Mon, 13 Oct 2008 18:04:53 +0000

In Java, Map is an interface, so we have to talk about specific implementations, like TreeMap and HashMap.

Objects are the real killer, though. Every object stores a reference (4 byte integer) as well as a pointer to the class itself (4 byte integer, I think), so you’re in for 8 bytes/object minimum. Strings store an underlying string (array of characters, meaning an object with associated pointer), as well as integer start/length, so you’re in for at least 24 bytes with an empty string.

Then if you look at HashMap, it’s structured as an array of Map.Entry implementations. HashMap implements Map. Entry as linked lists, with a generic key, generic value, next value, and integer hash, so 16 bytes plus object overhead, so about 24 bytes.

I think this can actually be worse in that some implementations store a 4-byte synchronization key on every object.

And it’s not just size — all the hash lookups are extremely slow compared to the basic multiply/add operation of a linear classify.

It’s possible to make smaller map implementations, as I do implicitly with tries in the lm package and with and the util.SmallObjectToDouble map class in LingPipe. (SmallSet is easier to understand and more general if anyone’s looking for examples.)

By: Jon

Jon — Sun, 12 Oct 2008 15:02:28 +0000

We had to do a similar optimization when we built our classification server. In C++ each STL map entry has an overhead of 28 bytes if I recall correctly, and strings in best case 4 bytes, worst case (strings longer than 16) 20 bytes. Using maps and strings for features was not possible for large frequency distributions – using an intermediate map for training which is “compacted” into raw memory (where we can do binary search) every now and then lowered memory consumption a lot. Do you know how much overhead maps have in Java?

Nice blog, keep up the good work! /Jon