> maybe thats because we have one huge monolithic implementation Doesn't the DocValues branch solve this?
Also, instead of trying to implement clever ways of compressing strings in the field cache, which probably won't bare fruit, I'd prefer to look at [eventually] MMap'ing (using DV) the field caches to avoid the loading and heap costs, which are signifcant. I'm not sure if we can easily MMap packed ints and the shared byte[], though it seems fairly doable? On Thu, May 19, 2011 at 6:05 AM, Robert Muir <rcm...@gmail.com> wrote: > 2011/5/19 Michael McCandless <luc...@mikemccandless.com>: > >> Of course, for >> certain apps that perf hit is justified, so probably we should make >> this an option when populating field cache (ie, in-memory storage >> option of using an FST vs using packed ints/byte[]). >> > > or should we actually try to have different fieldcacheimpls? > > I see all these missions to refactor the thing, which always fail. > > maybe thats because we have one huge monolithic implementation. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
