RE: [gui-dev] QueryRouteTable.java.patch (second version)

Thanks for sending this in, Philippe.  Right now we're more concerned with
the memory that the BitSets use as opposed to the speed with which they're
processed.  We'd like to increase the default QRT size in order to
accommodate ultrapeers holding more leaves, but cannot do this until we come
up with a more memory-efficient table.  Currently, the QRT's of each leaf &
ultrapeer are using more memory than anything else while LimeWire is running
as an ultrapeer.

The problem is that the BitSet implementation that we're using (a customized
version of java.util.BitSet) is not sparse.  So, if the table is 1000
entries large, and the 999th entry is set, the bitset will allocate storage
for the former 998 entries.  The storage is extremely compact (one long per
64 entries), but the size requirements are still too large.  You can view
the waste of the BitSet by enabling the 'QRP %' and 'QRP Empty' columns in
the 'connections' table in LimeWire.  The QRP % column is a measure of how
full the table is with respect to the total size.  The QRP Empty column is
two numbers -- the first is the number of unused longs (a long that is
storing no 'set' bits), and the second is the number of longs allocated.  If
LimeWire is running as an ultrapeer, you'll see that for leaves the 'QRP
Empty' column has a very high first number and just a slightly higher second
number -- this means that the BitSet has allocated many unused longs in
order to store just the last few 'set' bits.

Thanks,
 Sam

> -----Original Message-----
> From: Philippe Verdy [mailto:[email protected]]
> Sent: Saturday, November 27, 2004 7:44 PM
> To: [email protected]
> Subject: [gui-dev] QueryRouteTable.java.patch (second version)
> 
> Hello Sam (Berlin) and LimeWire developers,
> 
> You may have noticed the proposed patch for QueryRouteTable I proposed
> yesterday.
> After reflection, I have refined this patch, for faster computing of
> patches, by reducing the number of calls to BitSet methods, so that I will
> group updates to the generated data.
> Some more optimizations are possible notably in the patch decoders.
> But for the 1-bit and 2-bit formats, the difference of speed is very
> significant, and it is still visible for the 4-bit format and as well in
> the
> 8-bit patch format.
> See the attachment...
> (Note that the new supported 2-bit and 1-bit formats can easily be
> disabled
> by enabling the few comment lines starting at "2-BIT FORMAT PARSING" and
> "2-BIT FORMAT GENERATION")

_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev