I did some rough estimates of RAM usage for StringIndex (trunk) vs
Java String is an object, so estimate 8 byte object header in the JRE.
It seems to have 3 int fields (offset, count, hashCode), from
OpenJDK's sources, plus ref to char.
The char has 8 byte object header, int length, and actual array
So in trunk's StringIndex:
per-unique-term: 40 bytes (48 on 64bit jre) + 2*length-of-string-in-UTF16
per-doc: 4 bytes (8 bytes on 64 bit)
In the patch:
per-unique-term: ceil(log2(totalUTF8BytesTermData)) + utf8 bytes + 1 or 2 bytes (vInt, for term length)
per-doc: ceil(log2(numUniqueTerm)) bits
So eg say you have an English title field, avg length 40 chars, and
assume always unique. On a 5M doc index, trunk would take ~591MB and
patch would take ~226 MB (32bit JRE) = 62% less.
But if you have a CJK title field, avg 10 chars (may be highish), it's
less savings because UTF8 takes 50% more RAM than UTF16 does for CJK
(and others). Trunk would take ~305MB and patch ~178MB (32bit JRE) =
Also don't forget the GC load of having 5M String & char objects...