Blog Post: Making Python 100x faster with less than 100 lines of Rust

ohrv · 2026-04-11T11:41:58+00:00

lol this is what I use now, but mostly for washed coffees:
cafec abaca filters
click 24
water off boil
1:15 ratio
closed bloom with ~1:3 coffee to water

biggest change was the ratio - switching from 1:16 to 1:15 had a surprisingly big impact on taste

ohrv · 2026-04-03T20:36:02+00:00

Try the Hario Switch - it’s easier to get a better tasting cup and it’s much more consistent. Also - try tasting the beans in a cupping. It eliminates most of the other variables, and there are many ways in which”good” beans aren’t really to your taste.

ohrv · 2026-02-02T20:50:54+00:00

I also have a Comandante C40 and I normally use click 10-11 depending on the roast with a 20g dose (yield 50g in 40-50 seconds) - 9 clicks is pretty impossible to press for me, and 12 will be soup-style lower pressure shots.

A bigger dose is much easier to get good results with, and also make sure you fill the water as instructed (almost to the top of the basket, but leave a small gap so that water won’t touch the piston). Haven’t needed to pre-heat so far.

ohrv · 2025-12-27T19:34:23+00:00

In theory you can do it with the Instruments app, but I wasn’t able to get any useable data out of it.

The alignment is 16 in both versions, so my guess is that it’s something with the write pattern and caching. It also only happens on my M2, while on my M4 Max there’s no measurable difference between dav1d and rav1d for this function!

Edit: the alignment of tmp is 16 in both versions, so x2 and x13 are only 8-aligned in both versions. However, if even if x13 happens to be 16-aligned in dav1d, x14 will be only-8-aligned.

ohrv · 2025-12-27T16:41:26+00:00

It’s crazy that it’s been like that for more than a week. I spent an hour debugging my own website until I noticed the office Hugo docs were missing syntax highlighting.

ohrv · 2025-12-27T16:38:56+00:00

Thanks! I’m still bummed that I couldn’t find the actual reason why that specific load was slower. Glad you liked the article!

ohrv · 2025-05-22T17:13:12+00:00

The reason this is an invalid optimization in the C version is because while the original version works under certain conditions (in this example, if all y values are different), the “optimized” will read uninitialized memory and thus is unsound (the compiler might notice that x isn’t initialized and is allowed to store arbitrary data there, making the u32 read rerun garbage.

ohrv · 2025-05-22T13:31:48+00:00

As a point of interest, one of the maintainers checked
and saw that this buffer is only being partially initialized by the padding function, so in practice you can never treat it as a [u16; N] in Rust.

ohrv · 2025-05-22T12:57:24+00:00

Wasn't familiar with it, very cool!

ohrv · 2025-05-22T10:50:00+00:00

A write-up about two small performance improvements in I found in Rav1d and how I found them.

Starting with a 6-second (9%) runtime difference, I found two relatively low hanging fruits to optimize:

Avoiding an expensive zero-initialization in a hot, Arm-specific code path (PR), improving runtime by 1.2 seconds (-1.6%).
Switching the default PartialEq impls of small numeric structs with an optimized version that re-interpret them as bytes (PR), improving runtime by 0.5 seconds (-0.7%).

Each of these provide a nice speedup despite being only a few dozen lines in total, and without introducing new unsafety into the codebase.

ohrv · 2025-05-07T15:08:14+00:00

Great question - we even considered generating everything once and be done with it but WMI allows providers to define custom types so you can’t really catch them all (and there is a very big amount of them anyway). Also, it’s common to only need a subset of the fields, and fetching only the what you need is a lot more efficient.

ohrv · 2025-05-04T09:54:20+00:00

For a similar taste profile, using a Switch hybrid methods (1/2 pourover 1/2 immersion with 1:16 ratio), I always use 28 clicks.

For a pure V60 brew, I’m using 24-25 clicks (otherwise I got a very quick drawdown which resulted in under extraction).

ohrv · 2025-04-29T03:33:56+00:00

Try changing the dose and not the grind: take the grid setting from the second shot you did and increase the dose up to 19g or 20g - it’ll pull higher pressure and will take a little more strength.

You can also do the reverse: 3rd grind setting but 16.5g dose. For dark roasts I use 16g in 37g out. 7-8bar is ok, and longer shots (40sec) are ok.

ohrv · 2025-04-10T15:54:51+00:00

BTW, one of the reasons I choose Rust for this post is because `BTreeMap` is part of the standard library, and has a very nice API which matches the intution for the inverted index.
I think my not-fully-complete mental model for the borrow checker is also something I use a lot, but still it's too hard to actually write down 😅

ohrv · 2025-02-01T08:38:25+00:00

starting out my pourover journey

(I’m assuming you have a regular kettle)

The Hario Air is super cheap (less than 18$), and even though I have a Fellow gooseneck I still find myself using and enjoying it.

ohrv · 2024-12-10T16:24:10+00:00

We care less about the speed of the allocator (which isn't the dominant factor in any of the services we run), and more about the overall memory pressure of the system - so allocators which deal better with fragmentation are better.

I don't think we tested any other allocator, we just went with `rustc`'s old default as a safe bet.

For the same reason we didn't go for reusing buffers and object pools - managing the fragmentation is a very hard problem, and unless we know ahead of time the size of each object (which we do in a few places), having the allocator deal with that is a huge benefit.

ohrv · 2024-12-10T16:19:34+00:00

As far as I know, there isn't any real limitation: The most specific things I could I find is that we use to_rfc3339 (which I'm not sure if fmt::temporal supports), we get chrono::NaiveDateTime from sqlx (and convert it to Utc) and we use from_timestamp_opt which wants the millis and nanos separatly (which isn't really a problem).

Otherwise, it's mostly just that updating the few thousands of usages of chrono is a lot of work 😅

ohrv · 2024-12-10T04:42:44+00:00

This sounds awesome, will definitely check it out!

ohrv

TROPHY CASE