4 ms·

I have several hundred unit tests and also a bunch of integration tests. While UTs usually test API of individual classes, each of the ITs creates a swarm of lo

I have several hundred unit tests and also a bunch of integration tests. While UTs usually test API of individual classes, each of the ITs creates a swarm of local peers and launches a torrenting session with certain conditions: seeders to leechers ratio, downloading from .torrent file vs using a magnet link, PEX enabled/disabled, encrypted vs raw message streams, etc. Benchmarks (like in libtorrent) is something I'm looking forward to, but the project is still in the early stage -- there's a lot to be done with regards to optimization, i.e. switching to using NIO selectors, adding a caching layer, etc. That's a lot of work, and that's why I'm looking for collaborators, before investing more time into performance-tuning.

silotis 9y ago
I would advise against implementing a custom cache for piece data. Caching file data in-app is counterproductive because it wastes memory duplicating data which the OS already holds in its page cache. Instead memory mapped I/O should be preferred.
- atomashpolskiy 9y ago
  It makes sense, what would you advise in case of big files that don't fit into memory (or when it's undesirable to use big amounts of RAM, and speed can be sacrificed)? Maybe caching should be disabled by default but with the option to turn it on if the user wants it?
  - the8472 9y ago
    you can memory-map files in chunks and keep references to the mapped buffers or evict them once a certain limit is reached. note that mapped buffers are not necessarily backed by RAM, they act more like swap space, except it goes straight to the original file instead of a swap partition. the downside is that anything reading from the buffer can unpredictably incur IO overhead if there's memory pressure and the OS decides to not back them with memory. java doesn't have an api to check residency of buffers. a possible workaround is to first queue them up on a separate thread and forcing them in before using. if they're already there it should have low latency. if they aren't then only the victim thread eats the IO penalty.
    - atomashpolskiy 9y ago
      So, something like LRU cache of MappedByteBuffers, one buffer per chunk (i.e. "piece")? I wonder what queueing strategy would look like, just enqueue a couple of subsequent pieces when one is requested and loaded?
      - the8472 9y ago
        Start simple, then heap on optimizations if there are latency or throughput issues.
    - the8472 9y ago
      > java doesn't have an api to check residency of buffers. Too late to edit now, but I misremembered that part. I think the issue was that isLoaded was not entirely reliable.

silotis 9y ago

I would advise against implementing a custom cache for piece data. Caching file data in-app is counterproductive because it wastes memory duplicating data which the OS already holds in its page cache. Instead memory mapped I/O should be preferred.

atomashpolskiy 9y ago
It makes sense, what would you advise in case of big files that don't fit into memory (or when it's undesirable to use big amounts of RAM, and speed can be sacrificed)? Maybe caching should be disabled by default but with the option to turn it on if the user wants it?
- the8472 9y ago
  you can memory-map files in chunks and keep references to the mapped buffers or evict them once a certain limit is reached. note that mapped buffers are not necessarily backed by RAM, they act more like swap space, except it goes straight to the original file instead of a swap partition. the downside is that anything reading from the buffer can unpredictably incur IO overhead if there's memory pressure and the OS decides to not back them with memory. java doesn't have an api to check residency of buffers. a possible workaround is to first queue them up on a separate thread and forcing them in before using. if they're already there it should have low latency. if they aren't then only the victim thread eats the IO penalty.
  - atomashpolskiy 9y ago
    So, something like LRU cache of MappedByteBuffers, one buffer per chunk (i.e. "piece")? I wonder what queueing strategy would look like, just enqueue a couple of subsequent pieces when one is requested and loaded?
    - the8472 9y ago
      Start simple, then heap on optimizations if there are latency or throughput issues.
  - the8472 9y ago
    > java doesn't have an api to check residency of buffers. Too late to edit now, but I misremembered that part. I think the issue was that isLoaded was not entirely reliable.