mirror of
https://github.com/YGGverse/aquatic.git
synced 2026-03-31 17:55:36 +00:00
8d7cbb7926
DashMap doesn't scale as well as I had hoped. Only the scrape handler performed somewhat better with more threads, since it doesn't exlusively lock the torrent map. The announce and connect handlers, however, gained barely nothing from more threads.
60 lines
2.4 KiB
Markdown
60 lines
2.4 KiB
Markdown
# TODO
|
|
|
|
* Benchmarks
|
|
* Iterate over whole returned buffer and run e.g. xor on it (.iter().fold())
|
|
* Generic bench function since current functions are almost identical
|
|
* Show percentile stats for peers per torrent
|
|
* aquatic
|
|
* Tests
|
|
* Handle Ipv4 and Ipv6 peers. Probably split state. Ipv4 peers can't make
|
|
use of Ipv6 ones. Ipv6 ones may or may note be able to make use of Ipv4
|
|
ones, have to check.
|
|
* bittorrent_udp
|
|
* other test cases
|
|
* Check if announce response to bytes code changed caused slowdown
|
|
|
|
## Not important
|
|
|
|
* extract_response_peers
|
|
* Cleaner code
|
|
* Stack-allocated vector?
|
|
* Benchmarks
|
|
* num_rounds command line argument
|
|
* Send in connect reponse ids to other functions as integration test
|
|
* Save last results, check if difference is significant?
|
|
* ProgressBar: `[{elapsed_precise}]` and eta_precise?
|
|
* Test server over udp socket instead?
|
|
* Performance
|
|
* cpu-target=native good?
|
|
* mialloc good?
|
|
* Use less bytes from PeerId for hashing? Would need to implement
|
|
"faulty" PartialEq too (on PeerMapKey, which would be OK)
|
|
* Seperate dashmap for torrent stats, meaning there will be no
|
|
contention across announce and scrape requests. Will however
|
|
require two lookups in announce requests. Do this?
|
|
* bittorrent_udp
|
|
* ParseError enum maybe, with `Option<TransactionId>`
|
|
* Avoid heap allocation in general if it can be avoided?
|
|
* request from bytes for scrape: use arrayvec with some max size for
|
|
torrents? With Vec, allocation takes quite a bit of CPU time
|
|
* Optimize bytes to scrape request: Vec::with_capacity or other solution (SmallVec?)
|
|
|
|
# Don't do
|
|
|
|
## aquatic
|
|
|
|
* Other HashMap hashers (such as SeaHash): seemingly not worthwhile (might be
|
|
with AVX though)
|
|
* `sendmmsg`: can't send to multiple socket addresses, so doesn't help
|
|
* Config behind Arc in state: it is likely better to be able to pass it around
|
|
without state
|
|
* Responses: make vecors iteretor references so we dont have run .collect().
|
|
Doesn't work since it means conversion to bytes must be done while holding
|
|
readable reference to entry in torrent map, hurting concurrency.
|
|
|
|
## bittorrent_udp
|
|
|
|
* Use `bytes` crate for bittorrent_udp: seems to worsen performance somewhat
|
|
* Zerocopy (https://docs.rs/zerocopy/0.3.0/zerocopy/index.html) for requests
|
|
and responses? Doesn't work on Vec etc
|
|
* New array buffer each time in response_to_bytes: doesn't help performance
|