It's very optimized for in memory use, so assuming the db is all in working memory and the code operating on the data is in L1/L2, and for the type of data in the column store (Kdb+), you usually pull related chunks into the Lx data cache on which you filter. I would say k is fast for the use case where column memory based storage is a good fit, so relatively small data sets that live in memory and where the operations on the data fit column stores well; I would bet almost all k programmers (including myself) mostly have experience with those datasets or have shoehorned less suitable cases into that case because it did not perform otherwise.

There is obviously no magic, besides, for many 'new' programmers and for current standards, the incredibly small binaries for so much functionality. And that helps with always staying in cache vs almost every other software you will use these days where there is continues chunks of instruction data going to and from cache. That's why C (and maybe Rust some time in the future but the binaries were too large when I last checked) is still important if you really want to get to that point.

Ofcourse in that 200something kb k/kdb+/q binary there is no room for much optimizing, that is why it absolutely falls down for cases it was not optimized for. And when you use a lot of k you know how (and automatically do) to shoehorn basically anything in those cases.

It is not magic by any means, but it comes closer to magic for many as it is alien like assembly compared to JS or C# or something like that I guess. And the speed comes from keeping to your niches.

> Also, there are plenty of memory allocators

As I understand it, he did it because he did not find the Windows memory allocator efficient enough specifically; not sure why he didn't check for other allocators; I guess because he was optimizing a runtime, he just rolled his own instead.