Leandro Pereira, author of the Lwan web server, writes about C, Forth, coroutines, and Z80 retro computing.
HN links it as a source of systems-level C techniques, such as coroutine async I/O and string switch, and commenters call it interesting for systems programmers.
> Lookup tables are always faster than calculation - is that true?
Maybe on the Z80. Contemporary RAM was quite fast compared to it, by our sad standards.
A table lookup per byte will see you hit a pretty hard limit of about 1 cycle per byte on all x86 CPUs of the last decade. If you’re doing a state machine or a multistage table[1] where the next table index depends on both the next byte and the previous table value, you’ll be lucky to see half that. Outracing your SSD[2] you’re not, with this approach.
If instead you can load a 64-bit chunk (or several!) at a time, you’ll have quite a bit of leeway to do some computation to it before you’re losing to the lookup table, especially considering you’ve got fast shifts and even multiplies (another difference from the Z80). And if you’re doing 128- or 256-bit vectors, you’ve got even more compute budget—but you’re also going to spend a good portion of it just shuffling the right bytes into the right positions. Ultimately, though, one of your best tools there is going to be ... an instruction that does 16 resp. 32 lookups in a 16-entry table at a time[3].
So no, if you want to be fast on longer pieces of data, in-memory tables are not your friend. On smaller data, with just a couple of lookups, they could be[4]. In any case, you need to be thinking about your code’s performance in detail for these things to matter—I can’t think of a situation where “prefer a lookup table” is a useful heuristic. “Consider a lookup table” (then…
yeah i like this model. then you can use whatever synchronization junk you prefer to share state between the threads, if you have any.
your library looks well written and clean. thanks for sharing.
if anyone else wants to go coroutine spelunking, these were interesting to me:
https://github.com/higan-emu/libco/tree/master
https://github.com/Tencent/libco
https://github.com/hnes/libaco
https://kernel.googlesource.com/pub/scm/virt/kvm/qemu-kvm/+/acd3b6be325a66f8f10f0eed19ed5261ced411cf/coroutine-sigaltstack.c
https://tia.mat.br/posts/2012/09/29/asynchronous_i_o_in_c_with_coroutines.html
https://www.cs.uml.edu/~bill/cs516/context_paper_rse-pmt.pdf
The bit vector does give a nice compression compared to the jump table. But I believe the main thing to do for speeding up string parsing is to consume more than one character at a time. I personally found the techniques in https://tia.mat.br/posts/2018/02/01/more_on_string_switch_in_c.html very helpful to explain these issues.
EDIT: I especially like this statement from the conclusion:
> The good thing about the switch statement in C is that it is maybe the highest level statement in the language: the compiler can get really creative in how its code is generated. It's not uncommon for it to generate jump tables or even binary searches.
I recently wrote one, in C, using tail calls to implement dispatch with CPS: https://tia.mat.br/posts/2025/08/30/forth-haiku.html
It's already pretty efficient but I'm working on it to make it even more efficient so I can use it as some sort of primitive fragment shader for an art project. This Forth variant is intended to execute Forth Haikus, as defined by the Forth Salon website.
For more information on some of the C magic behind this well-written piece of software, check out the authors blog[1]. It should be pretty interesting for any systems programmer.
[1]: http://tia.mat.br/blog/html/index.html
The section on Coroutines links to itself; perhaps you meant it to link to your other article on Coroutines? (http://tia.mat.br/blog/html/2012/09/29/asynchronous_i_o_in_c_with_coroutines.html)