Interesting, the decompressor in Jdeflate is around 4k LoC. https://github.com/Jpn666/jdeflate

>the only flag we care about is FNAME The specification does not define an encoding for the file name. Different file systems may impose restrictions on certain names, so FNAME should not be used.

If you need to optimize the allocator you are doing it wrong.

That's a false dichotomy: you optimize both the application and the allocator.

A 0.5% improvement may not be a lot to you, but at hyperscaler scale it's well worth staffing a team to work on it, with the added benefit of having people on hand that can investigate subtle bugs and pathological perf behaviors.

exactly. I can think of at least 5 different projects I have been on where a better allocator would made a world of difference. I can also think of another 5 where it probably would have been a waste of time to even fiddle with.

but as usual there is an xkcd for that. https://xkcd.com/1205/

One project I spent a bunch of time optimizing the write path of I/O. It was just using standard fwrite. But by staging items correctly it was an easy 10x speed win. Those optimizations sometimes stack up and count big. But it also had a few edges on it, so use with care.

Glad we have super slow allocators then

Exactly. No need to engineer an allocator. You only live once!

    void* malloc(size_t size) {
        void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
        return (ptr == MAP_FAILED) ? NULL : ptr;
    }

    void free(void *ptr) { /* YOLO */ }

/s

He has some good points. This one is from a different paper (Good Ideas, Through the Looking Glass):

Designers had ignored both the issue of efficiency and that a language serves the human reader, not just the automatic parser. If a language poses difficulties to parsers, it surely also poses difficulties for the human reader. Many languages would be clearer and cleaner had their designers been forced to use a simple parsing method.

What a waste of words. If you idea is easily replicable probably it was not a good idea after all. LLMs don't change the equation.

They absolutely did. Things were not necessarily easily reproducible before. Now they are.

Are they really

> easily

reproducible now?

>easily replicable probably it was not a good idea after all.

I mean, sometimes the hard work is creating object number 1. There are a crapload of inventions that we look back on and go "why did it take so long for us to make the first one", then after that whatever object/idea it was explodes over the planet because of the ease of implementation and the useful practical application.

I think this statement is marred by the our modern sensibilities that say everything must be profitable or it's a bad idea.

> If you idea is easily replicable probably it was not a good idea after all.

Yes.

> LLMs don't change the equation.

No. They make more things easily replicable.

"We made this and all it took was 500 juniors working for a year" used to be a reasonable business moat of effort. Now it's not.

Please don't do It.

No, it's not. It's just a form of Elias-Gamma coding.

* unary encoding coding.