Re: NIO uploads and downloads

A much less intrusive change that will have bigger and more
immediately visible benefit would be moving the verifying file to use
memmapped files.  For a large number of downloads all going at high
speeds, the difference in disk seek times, paging and general disk
load is staggering.  While it may sound like a trivial change, there
are several issues that need to be considered, the main one being the
2GB process limit which makes it impossible to mmap more than 2GB of
data through java.

Addressing this issue will not only result in faster downloads (yes,
they easily become limited by disk throughput) but will have very
positive effect on the commonly experienced "LimeWire slows down my
computer" complaint.  Admittedly, reducing the # of threads will
indirectly reduce memory usage which will in turn reduce OS paging,
but at the moment the overwhelming majority of disk load is generated
by the RandomAccessFile activities.

Also, moving other parts of the nio engine to use direct buffers
and/or optimized routines (uploads for example could use
FileChannel.write(OtherChannel)) can also yield some benefit.

On 10/15/05, Gregorio Roper <[email protected]> wrote:
> I'm looking at having LimeWire's uploads and downloads use Sam's nio
> infrastructure. The first problem I have encountered was the udpconnect
> package.
>
> It seems to me, the easiest way of making it compatible would be to stop
> trying to emulate a regular socket entirely and just offer an
> implementation of the com.limegroup.gnutella.io.NIOMultiplexor
> interface. Likewise I would remove the blocking
> UDPBufferedInput/OutputStreams in favor of Readable/WritableByteChannels.
>
> An issue that still remains is of course bandwidth management, - because
> the currently used NBThrottle class would be incompatible with any
> Throttle we would use for the UDP transfers.
>
> Comments and ideas greatly appreciated,
>
> thanks
> gregorio
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
>
>

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