Hash: SHA1


The JVM converts all shorts to ints before doing any arithmetic, so
shorts are actually a little bit slower than ints.

As for the size: If you have primitive values, an int takes up 4 byte,
whereas a short takes 2 bytes (+java overhead), meaning 100.000 * 3 int
rather than shorts should take up 600kbyte of memory more - hardly
noticeable compared to fops overall memory usage.

When you use the non-primitive types, java >= 1.5 uses the flyweight
pattern, meaning there is one instance for every number used, you would
only store a pointer, which has the same size for Integer and Short.

So +1 for making this change.


Andreas Delmelle schrieb:
> Hi all
> Just checking if anyone would mind terribly if the AreaInfo inner class
> in TextLayoutManager were changed to use 'int' indices rather than 'short'.
> AFAIK, this is the only reason we currently need to split up FOText
> instances larger than 32K characters. At the time I introduced this fix,
> I opted to split the FOText instances, since I was a bit concerned about
> a rise in memory consumption. Upon closer inspection, and some browsing
> around, this seems to have far less of an impact than I thought...
> I did a quick test, allocating space for an array of 100.000 instances of:
> - a wrapper around three short values (values Short.MAX_VALUE)
> - a wrapper around three int values (values Integer.MAX_VALUE)
> The results:
> - 3 shorts -> 100.000 instances = (2200K - 800K) = 1600K
> - 3 ints -> 100.000 instances = (2980K - 800K) = 2180K
> The 800K is subtracted to account for the instance size (8 bytes * 100K).
> So three ints do not take up 100% as much space (as I initially
> expected), but only roughly between 30% and 50%...
> Opinions?
> Cheers
> Andreas

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to