> Right, much less GC if app frequently reopens. But a 32X increase in > RAM usage is not trivial; I think we shouldn't enable it by default?
Right, the RAM usage is quite high! Is there a more compact representation we could use? Ah well, either way for good RT performance, there are some users who may want to use this option. > Have you tested? The test would be a basic benchmark of queries against BV vs. an int[] of deletes? On Tue, Jul 20, 2010 at 12:17 PM, Michael McCandless <[email protected]> wrote: > On Tue, Jul 20, 2010 at 1:44 PM, Jason Rutherglen > <[email protected]> wrote: >>> Breaking up RT patches into baby steps would be great :) >>> Actually is the RT branch active (I haven't seen commits going >>> in). >> >> From what we discussed, my impression is that the RT changes >> will be substantial and the sequence ids seem to be something >> that can be implemented now in trunk, then at least a small >> piece of RT would be implemented and tested. A small isolated >> improvement. > > I agree. > >>> The biggest downside of sequence IDs is increase RAM usage >>> right? >> >> Yes, however the garbage collection would decrease. > > Right, much less GC if app frequently reopens. But a 32X increase in > RAM usage is not trivial; I think we shouldn't enable it by default? > >> We should make seq id deletes pluggable. > > +1 -- make the deletes impl pluggable (ie one impl is sequence IDs; > another is BitVector). > >>> Then, checking if a doc is deleted becomes an int compare >>> instead of a bit lookup, right? >> >> Right it'd be an int compare, I think this'd be ok? > > Yeah maybe even more than OK; could be this is faster than looking up > a bit! (Though it's much more traffic on the memory bus). Apps may > want to use this even outside of NRT. Have you tested? > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
