-
Notifications
You must be signed in to change notification settings - Fork 8
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
cxlrubytes - fast zero alloc lru for []bytes only. i'll be honored to have your feedback on this lru i created for your comparison, remarks and comments #16
Comments
yes, I also think about it for a long time, I called it "BytesCache" before, please allow me share some thoughts:
|
@phuslu hope to hv your contribution to the repo too. in fact hope u to have you as one of the maintainers. |
I still have interests the roadmap of #15 (comment) Probably the cxlrubytes is simpler and faster choice in your case. But the rest parts(a mmaped and minimalized memory&gc bytes cache) of golang caches is still need someone(me) to make it done. I regard it as a technical challenge on a larger scale, worth work it out but maybe no one will ever use it. 😄 |
@phuslu i will use it. step 3 is difficult to find an elegant solution. if you can help solve the alloc first. step 3... well, yeah. but i will definitely use it if you can get it done |
maybe there're is a implicit copy action in |
@phuslu i thought there was issue, it was with my test code. the code is fine. still need some test. just got it working a few hours ago. it's usable and 100% zero alloc. p.s. : my other test code was the one generating the alloc. |
@phuslu i updated batch eviction to speed it up else 1 by 1 too slow. |
Congrats, I guess you currently fingure out that a most suitable solution for your case. BTW: considering https://github.com/cockroachdb/swiss impressive throughputs in large scale map, I think/guess the max performance solution of "lru as map" is forking the cockroachdb/swiss then add "prev/next" field to its entry to make it behavior like lru also. This is similar with what is elastic/go-freelru done before. In particular, swiss no longer requires the bucket size to grow by a power of 2, which will avoid the “overcommit” issue of freelru. |
The overhead of generic function calls(seems that it cannot be inlined) prevents deeper performance optimization, which is why I plan to make one "BytesCache" or "MmapCache". see golang/go#54766 (comment) and https://www.reddit.com/r/golang/comments/ts9neg/generics_can_make_your_go_code_slower/ |
@phuslu thx for sharing insights, will wait for ur mmap version with eager anticipation. |
@phuslu updated and fixed cxlrubytes on some performance issues etc, it's now a bit faster.
|
|
@phuslu i've tried map[uint32]uint32 here, it's faster but it's limited to 4 bil keys, there can be some use case etc. but for my use case, i prefer the map[string]int as it's more "secure". anyway, for your reference: i'm looking forward to the mmap version actually for now, but that's beyond me coz i cant figure out a reasonably fast global lock for it. |
i'll be honored to have your feedback on this lru i created for your comparison, remarks and comments.
hope to have your comments / input
https://github.com/cloudxaas/gocache/tree/main/lru/bytes
you can try on the hit / misses etc which i have no idea how you would do the benchmark comparison. thx in advance.
i created it coz most lru need to predefined a capacity but i would prefer to be limited by memory size set.
i've been following your lru for some time and your analysis is the most comprehensive.
The text was updated successfully, but these errors were encountered: