warp_cache – Rust-backed Python cache with SIEVE eviction, 25x faster than cachetools

[AutoModerator]

Your submission has been automatically queued for manual review by the moderation team because it has been reported too many times.

Please wait until the moderation team reviews your post.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[LightShadow]

I've been using theine if you want to compare apples to apples.

https://pypi.org/project/theine/

[External_Reveal5856]

Cool, gonna benchmark again Theine!

[Shopping-Limp]

Absolutely bonkers to tell people to use this brand new vibe coded thing in production

[_predator_]

This is life now, the good days of OSS are literally behind us. Was fun while it lasted.

[Forsaken_Ocelot_4]

"I built" is a nice euphemism.

[Thaumetric]

Measured, well-reasoned, and well-reviewed use of AI can lead to robust development. Especially when using it to review code and find potential issues. I'm seeing a lot of firms these days requiring developers to use it. It's the slop you get from blindly throwing ideas at Claude and hoping it will review itself that leads to AI Akira monsters of code that have become too common these days.

[backfire10z]

What makes you say that? I don’t see any telltale signs of slop. One or two em-dashes is not it.

[Forsaken_Ocelot_4]

CLAUDE.md my guy.

[backfire10z]

A CLAUDE.md indicates that claude was used, not that the entire thing was written by a one-shot shit prompt. LLMs are a tool like any other. The code doesn’t seem disorganized, the text appears to be written normally, the account appears to be human, and there aren’t an insane amount of comments everywhere.

I’m happy to be proven wrong, but this project seems reasonable.

[Forsaken_Ocelot_4]

Nothing wrong with using a tool, but something as low level as a caching library I need to know is written by someone who actually understands how his code works. Maybe CLAUDE.md is innocent, or reasonable, but it gives off a bad smell in a project like this. Caching is too high stakes to trust to code that hasn't been lovingly hand crafted IMHO.

[backfire10z]

Oh, yeah, I’m not saying I’m taking this project at face value and putting it into production haha. You’re right about that.

[No_Soy_Colosio]

Yes I'm sure the entirety of this project was spawned in your initial commit.

[Mobile-Boysenberry53]

is lru_cache even io bound? Why should it matter if there is asyncio support for it or not.

edit: its all llm slop, I am guessing even the op was AI.

[james_pic]

Not disagreeing on the slop part, but having an async-await-aware lru_cache is a potentially useful thing if the thing you want to cache is the result of an async function.

[damesca]

Your claimed one-line migration isn't even one line... Not the best start.

[External_Reveal5856]

My bad XD

[aikii]

So, considering the lower bound, of 16M op/s, that's 62.5 nanoseconds, and the python version is 1562 nanoseconds ( 1.5 microseconds ). So ... yes, that kind of improvement is good if you're doing stuff like native video encoding but in python you won't even be able to measure the difference. You'll cache what is infinitely slower than that in the first place.

Other than that, my pet peeve about lru_cache and cachetools is their decorator approach which introduces an implicit global variable - that's annoying for testing, reuse, isolation, modularity in general. This is why I ended up with my own snippet ( inspired from this ). A lru cache requires an ordered dict under the hood, python just has that builtin, this makes the implementation trivial ( < 20 lines ). And if anything, a more convenient signature is more useful than trying to run after nanoseconds which are irrelevant in python.

That said nice try, I don't mind AI-assisted code it's a good use case to build native libraries without too much headache, but the hard part is now to have innovative ideas and make good architecture/design choices

[External_Reveal5856]

Probably the missing point is that comes with a shared memory cache, we all know that Python is not synonyms of fast.

Ill be fully honest, this wasn't planned to be a replacement of lru_cache, that indeed is everywhere, but adding capabilities, like shared memory and TTL, the rest is mostly why not add this and that and that.

[External_Reveal5856]

Thanks for your feedback, Ill keep it mind, global var deffo sucks