: > What do you think about that alternative approach I mentioned? Instead of having FieldCacheImpl be aware of all IndexReaders, have FieldCache be an inst var in IndexReader? : : I wonder why it wasn't done that way to start with.... perhaps to : completely separate sorting from index reading. Anyway, it's not : backward compatible, and it doesn't buy us much to change now does it? : We would get rid of a singe hash lookup on the reader, which is : insignificant compared to anything the FieldCache is used for anyway.
the discussion on this i'm remembering was here... http://www.nabble.com/Poor-performance-%22race-condition%22-in-FieldSortedHitQueue-tf2070773.html#a5767432 Doron speculated that the reason FieldCache was seperate from IndexReader was to keep the "caching" at a higher level then the "reading", i suggested that if we're going to change the API, we should move the "refrence" to the cache up into the Searcher since that's the place Sorting is acctually done, but that it should still be based on weak ref to the reader since multiple searchers might share a reader. thinking about it now however, i would think it does make sense for the IndexReader to hang on to it's field cache ... it would not only simplify things a lot, and allow an IndexReader to explicilty "clear" it's cache when it's closed, but it would also allow us to intellegently populate the cache based on the individual segments in a MultiReader (so if some of hte segments haven't hcange,d we don't reread that part of hte cache) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
