lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2380) Add FieldCache.getTermBytes, to load term data as byte[]
Date Tue, 25 May 2010 20:35:35 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871342#action_12871342
] 

Michael McCandless commented on LUCENE-2380:
--------------------------------------------

I did some rough estimates of RAM usage for StringIndex (trunk) vs
TermIndex (patch).

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
data.

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) =
42% less.

Also don't forget the GC load of having 5M String & char[] objects...


> Add FieldCache.getTermBytes, to load term data as byte[]
> --------------------------------------------------------
>
>                 Key: LUCENE-2380
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2380
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.0
>
>         Attachments: LUCENE-2380.patch, LUCENE-2380.patch, LUCENE-2380.patch
>
>
> With flex, a term is now an opaque byte[] (typically, utf8 encoded unicode string, but
not necessarily), so we need to push this up the search stack.
> FieldCache now has getStrings and getStringIndex; we need corresponding methods to load
terms as native byte[], since in general they may not be representable as String.  This should
be quite a bit more RAM efficient too, for US ascii content since each character would then
use 1 byte not 2.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message