-
-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement cache layer for file storage #265
Comments
Can we get some /debug/perf outputs for this? It will help ensure I'm on track with my intended fixes. In particular this:
|
@anacrolix
please let me know if you need additional information. thank you! p.s. I also suffer from #234 - with memory storage i have in average 70% (3-4 MB/s) of speed that libtorrent/quasar gives, but download speed it is not |
Thanks @antonsoroko . I don't have time to get to this at the moment. The pastes will be very useful. |
Same here. Every time I try to use "Use File" option, my speed slows down (about 1MB/s or less) and takes a lot to start, seems download almost full file before start. |
https://golang.org/pkg/io/#CopyBuffer would likely do what you want without needing to implement caching. |
@james-lawrence I don't think it's that straight forward. Other implementations maintain a queue of chunks in memory, and try to coalesce the writes. Additionally there's an opportunity to cache file descriptors in the file storage. It's hard for me to directly address these without good profiling available. |
There have been significant changes to requesting and storage implementations since this issue was created. In particular, the request strategy now often requests pieces and their chunks in order so they may write out faster. There is still no caching implementation though. |
This was mentioned in #234.
Disk operations are not so great on Windows/Android systems.
So we can add a disk cache from our side to collect write operations and flush them once buffer if filled up or periodically.
This one is implemented in libtorrent. Some interesting points there: https://github.com/arvidn/libtorrent/blob/master/src/disk_io_thread.cpp#L874 and https://github.com/arvidn/libtorrent/blob/master/src/disk_io_thread.cpp#L1679 .
Not sure we need that level of complexity.
I was looking at golang's bufio implementation (https://golang.org/src/bufio/bufio.go?s=14456:14486#L599) which is pretty simple. We just miss offset writes, and, probably, need to collect multiple consequent chunks into one bigger write operation.
Probably have to manage flushing if need to verify the piece or something.
The text was updated successfully, but these errors were encountered: