Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analyzing the codebase of Caffeine, a high performance caching library

adriacabeza.github.io

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Analyzing the codebase of Caffeine, a high performance caching library

#21

Post by homebrewer »

dstroot wrote: post #18

Codebase has >16k stars on GitHub and only 1 open issue, and 3 open PRs. Never seen that before on a highly used codebase. Kudos to the maintainer(s).

kitty is very close, which is impressive when you remember that the vast majority of the work is done by one guy (Kovid Goyal).

https://github.com/kovidgoyal/kitty/issues — 0.239% vs 0.137%

https://github.com/kovidgoyal/kitty/issues — 0.729% vs 0.317%

https://github.com/kovidgoyal/kitty/graphs/contributors

Re: Analyzing the codebase of Caffeine, a high performance caching library

#22

Post by NovaX »

jedberg wrote: post #12

It would be interesting to see this on reddit's workload. The entire system was designed around the cache getting a 95%+ hit rate, because basically anything on front page of the top 1000 subreddits will get the overwhelming majority of traffic, so the cache is mostly filled with that. In other words, this solves the problem of "one hit wonders" getting out of the cache quickly, but that basically already happened wi…

Doesn’t reddit use Cassandra, Solr, and Kafka which uses Caffeine?

Re: Analyzing the codebase of Caffeine, a high performance caching library

#24

Post by ketzo »

bean-weevil wrote: post #20
dstroot wrote: post #18

Codebase has >16k stars on GitHub and only 1 open issue, and 3 open PRs. Never seen that before on a highly used codebase. Kudos to the maintainer(s).

I went through some of the issues to see how aggressively they close them and found this gem: https://github.com/ben-manes/caffeine/issues/1824#issuecomme...

Damn, I need that framed over my desk.

Re: Analyzing the codebase of Caffeine, a high performance caching library

#25

Post by Lord_Zero »

dstroot wrote: post #18

Codebase has >16k stars on GitHub and only 1 open issue, and 3 open PRs. Never seen that before on a highly used codebase. Kudos to the maintainer(s).

I haven't looked, but stalebot can make repos look squeaky clean when in reality issues are ignored and then closed without being addressed.

Re: Analyzing the codebase of Caffeine, a high performance caching library

#26

Post by calpaterson »

Lord_Zero wrote: post #25
dstroot wrote: post #18

Codebase has >16k stars on GitHub and only 1 open issue, and 3 open PRs. Never seen that before on a highly used codebase. Kudos to the maintainer(s).

I haven't looked, but stalebot can make repos look squeaky clean when in reality issues are ignored and then closed without being addressed.

Sparing everyone else a browse of the bugtracker: the maintainer does not seem to use a bot to autoclose issues. The close issues appeared to be actually closed and it seemed from a quick glance that he actually investigated each filing.

Re: Analyzing the codebase of Caffeine, a high performance caching library

#28

Post by NovaX »

quotemstr wrote: post #23

Huh. Their segmented LRU setup is similar to the Linux kernel's active and inactive lists for pages. Convergent evolution in action.

I tried to reimplement Linux’s algorithm in [1], but I cannot be sure about correctness. They adjust the fixed sizes at construction based on device’s total memory, so it varies if a phone or server. This fast trace simulation in the CI [2] may be informative (see DClock). Segmentation is very common, where algorithms differ by how they promote and how/if they adapt the sizes.

[1] https://github.com/ben-manes/caffeine/blob/master/simulator/...

[2] https://github.com/ben-manes/caffeine/actions/runs/130865965...

Re: Analyzing the codebase of Caffeine, a high performance caching library

#29

Post by NovaX »

jbellis wrote: post #14

Caffeine is a gem. Does what it claims, no drama, no scope creep, just works. I've used it in anger multiple times, most notably in Apache Cassandra and DataStax Astra, where it handles massive workloads invisibly, just like you'd want. Shoutout to author Ben Manes if he sees this -- thanks for the great work!

Thanks Jonathan!
Post reply on HN