> Uses 1.5GB of RAM on my laptop atm.

That's crazy, I just checked on mine (macOS), it's only ~300MiB, about as much as Apple Mail which is native.

Still a bit much for what I need it for, but tolerable.

TruffleRuby is pretty close too, if anything it’s even a bit more compatible because it’s able to run native extensions.

Also keeping compatible with MRI have been made significantly easier by Prism, the new parser that is shared by all implementations.

Thanks for the clarification. I thought Prism is still in beta. Maybe I'm wrong

Nope. It’s been the default MRI parser for a couple years now.

> lost 3 of 3 members of the Open Source Committee (Gabi, Mike, Ufuk)

This is rich given they left in big part because of how much abuse they have received by "supporters" of André & co...

There's a public survey: https://surveys.ecb.europa.eu/10b/neweuro/

Thank you. I wish they had used a pairwise comparison system like the one built by pil0u [1] for this. If I hadn't looked at all of them in advance, I would've had to go back to "normalize" my previous answers after seeing one that I especially like/hate.

[1]: https://news.ycombinator.com/item?id=49041625

That's why C23 introduce free_sized [0].

[0] https://en.cppreference.com/c/memory/free_sized

>> If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important.

> That's why C23 introduce free_sized

Is it? C23 still has free, so there’s no guarantee callers wil use free_sized, so the allocator still has to be able to obtain a block’s size from a pointer.

Or do I overlook something?

I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function

Because free still exists and there is no “allocate this number of bytes of memory; I promise to free it with a call to free_size” call, you can’t have a malloc implementation that doesn’t track block sizes.

I think the only thing free_size adds is robustness. Allocators can check the passed in size with what they know and abort the program if they do not match. That can thwart some security issues.

Similarly, when writing Facebook apps with Rails, when you'd hit that same bug you'd see Mark Zuckerbeg: https://www.facebook.com/profile.php?id=4

It was just one of many.

Alone it wouldn't have been very noticeable, but I did many small optimizations like that, which ultimately shaved about 20 seconds of setup time.

Looking from another angle, the app boot time on CI (not eager loading) was a bit more than 10 seconds, this saved over half a second, so a ~5% gain for an afternoon of work.

that sounds nice, thanks for sharing The Numbers! :D

Nothing ground breaking we simply deploy Buildkite agents on EC2 nodes.

As mentioned in the post, the only thing really limiting CI parallelism is the ratio of "setup time" vs "test time". If your setup time is too long, you hit diminishing returns fast.

Thank you for sharing – with 1350 workers I can appreciate the reduction of setup time!

Aside from the oddness of making this cache git aware, with the new implementation I suspect querying git to revalidate the cache would take longer than just rebuilding it.

Looking up the hash of a tree in git is few enough operations that I would be very surprised if that is true for all but the smallest caches. If you were to shell out to the git binary, maybe.