Re: NIO uploads and downloads

My idea was to have the HTTPDownloaders read the data directly from the 
socket to MappedByteBuffers. Since this won't be possible using 
Input/OutputStreams I want to make the whole downloader use NIO. 
Reducing the number of threads wasn't my primary goal and I'm not sure I 
would want to do that during the first pass...

mfg
gregorio

Zlatin Balevsky wrote:
> 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.
>   
_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev