3 ms·
Even in a database, most of the code isn't performance sensitive. Making your life a bit harder in the fast path so it's easier in the slow path is at least a t
by amarkov 9y ago
Even in a database, most of the code isn't performance sensitive. Making your life a bit harder in the fast path so it's easier in the slow path is at least a tradeoff worth considering.
- kllrnohj 9y agoYour fast path is still crippled by your slow paths' mess. It doesn't matter if you've isolated and optimized those paths in isolation, to the GC there's just Your Process and it's going to suspend Your Process whenever it wants for however long it needs regardless of what's currently happening. So if you're latency sensitive then all of your code needs to be aggressive at avoiding object creation. All of your code becomes part of "the fast path", even if it's in a different thread. Or you isolate your fast path in a different process or a non-GC'd runtime, the later being the approach taken here by Instagram.
- majidazimi 9y agoBased on previous research [1], almost every part of a DB is in the hot path. [1] http://15721.courses.cs.cmu.edu/spring2018/papers/02-inmemory/hstore-lookingglass.pdf http://15721.courses.cs.cmu.edu/spring2018/papers/02-inmemor...
- amarkov 9y agoI'd definitely believe that every part of query execution is in the hot path, as this paper describes. But most code in any reasonable DB system isn't part of query execution.