Optimizations

[aantron]

• Router: use a trie or a DFA instead of walking through all routes using CPS.
• Logger: logging is slower than could be expected. Make it as fast and/or asynchronous as possible. In early testing, a Hello, world! app responded in ~5 microseconds on my machine, but the logger added ~150 microseconds of overhead.
• Most web format parsers are naive and allocate a lot of intermediate strings and lists, probably contributing to GC pressure. Many of them also do multiple passes through the input. Almost all of them can be re-written into single-pass parsers that only allocate the final result.
• (Edit 9/4/2021) Stream files from the default static loader rather than reading them into memory.
• (12/4/2021) Minimize allocations during streaming (or measure them, including GC pressure).

Of course, everything should be measured first.

Some early notes from a few weeks ago:

  - request-id seems to take ~3 us.
  - catch ~1 us or less.
  - in-memory sessions 200 us on miss, 100 us on hit.
  - Initial form parser 9 us on tiny input; 30 us on larger, more realistic input
  - jwto CSRF tokens maybe 50 us.

[anuragsoni]

use a trie or a DFA instead of walking through all routes using CPS.

I experimented with this a lot when looking at routing implementation for routes. At the moment tries seemed like the most ideal approach when factoring in ease of implementation/maintenance (compared to dfa construction), and they allowed for easy composition of multiple routers. I also think tries will be fast enough for the vast majority of web applications and will probably have a more predictable memory usage as opposed to a dfa based solution.

[dinosaure]

If you want a fast trie, you should take a look on art which is a fast implementation of an Adaptive Radix Tree.