A 40-line fix eliminated a 400x performance gap(questdb.com)
148 pointsby bluestreak4 hours ago9 comments
  • ot2 hours ago
    You can do even faster, about 8ns (almost an additional 10x improvement) by using software perf events: PERF_COUNT_SW_TASK_CLOCK is thread CPU time, it can be read through a shared page (so no syscall, see perf_event_mmap_page), and then you add the delta since the last context switch with a single rdtsc call within a seqlock.

    This is not well documented unfortunately, and I'm not aware of open-source implementations of this.

    EDIT: Or maybe not, I'm not sure if PERF_COUNT_SW_TASK_CLOCK allows to select only user time. The kernel can definitely do it, but I don't know if the wiring is there. However this definitely works for overall thread CPU time.

    • jerrinot2 hours ago
      That's a brilliant trick. The setup overhead and permission requirements for perf_event might be heavy for arbitrary threads, but for long-lived threads it looks pretty awesome! Thanks for sharing!
      • ot2 hours ago
        Yes you need some lazy setup in thread-local state to use this. And short-lived threads should be avoided anyway :)
  • shermantanktopan hour ago
    Flamegraphs are wonderful.

    Me: looks at my code. "sure, ok, looks alright."

    Me: looks at the resulting flamegraph. "what the hell is this?!?!?"

    I've found all kinds of crazy stuff in codebases this way. Static initializers that aren't static, one-line logger calls that trigger expensive serialization, heavy string-parsing calls that don't memoize patterns, etc. Unfortunately some of those are my fault.

    • wging14 minutes ago
      I also like icicle graphs for this. They're flamegraphs, but aggregated in the reverse order. (I.e. if you have calls A->B->C and D->E->C, then both calls to C are aggregated together, rather than being stacked on top of B and E respectively. It can make it easier to see what's wrong when you have a bunch of distinct codepaths that all invoke a common library where you're spending too much time.)

      Regular flamegraphs are good too, icicle graphs are just another tool in the toolbox.

  • jerrinot4 hours ago
    Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
    • jacquesm3 hours ago
      I don't think it is possible to talk about fractions of nanoseconds without having an extremely good idea of the stability and accuracy of your clock. At best I think you could claim there is some kind of reduction but it is super hard to make such claims in the absolute without doing a massive amount of prep work to ensure that the measured times themselves are indeed accurate. You could be off by a large fraction and never know the difference. So unless there is a hidden atomic clock involved somewhere in these measurements I think they should be qualified somehow.
      • rcxdude3 hours ago
        Stability and accuracy, when applied to clocks, are generally about dynamic range, i.e. how good is the scale with which you are measuring time. So if you're talking about nanoseconds across a long time period, seconds or longer, then yeah, you probably should care about your clock. But when you're measuring nanoseconds out of a millisecond or microsecond, it really doesn't matter that much and you're going to be OK with the average crystal oscillator in a PC. (and if you're measuring a 10% difference like in the article, you're going to be fine with a mechanical clock as your reference if you can do the operation a billion times in a row).
        • jacquesm3 hours ago
          This setup is a user space program on a machine that is not exclusively dedicated to the test running all kinds of interrupts (and other tasks) left, right and center through the software under test.
    • Neywiny3 hours ago
      Did you look into the large spread on your distributions? Some of these span multiple orders of magnitude which is interesting
      • jerrinot3 hours ago
        Fair point. These were run on a standard dev workstation under load, which may account for the noise. I haven't done a deep dive into the outliers yet, but the distribution definitely warrants a more isolated look.
    • 6r173 hours ago
      Very thankful for the 1liner tldr

      edit : I had an afterthought about this because it ended up being a low quality comment ;

      Bringing up such TLDR give a lot of value to reading content, especially on HN, as it provides way more inertia and let focus on -

      reading this short form felt like that cool friend who gave you a heads up.

      • jerrinot3 hours ago
        I was unsure whether to post it or not so I am glad you found it useful!
        • 6r173 hours ago
          I have that 10-30s time window to fill when claude might be loading some stuff ; the 1 liner is exactly what fits in that window - it makes me wonder about the original idea of twitter now that I think of it - but since it's not the same kind of content I don't bother with it.It really feels like "here is the stuff, here's more about it if you want to" - really really appreciate that form and will definitely do the same format myself
  • furyofantaresan hour ago
    > Flame graph image

    > Click to zoom, open in a new tab for interactivity

    I admit I did not expect "Open Image in New Tab" to do what it said on the tin. I guess I was aware that it was possible with SVG but I don't think I've ever seen it done and was really not expecting it.

    • jerrinotan hour ago
      Courtesy of Brendan Gregg and his flamegraph.pl scripts: https://github.com/brendangregg/FlameGraph

      Normally, I use the generator included in async-profiler. It produces interactive HTML. But for this post, I used Brendan’s tool specifically to have a single, interactive SVG.

  • otterley43 minutes ago
    It took seven years to address this concern following the initial bug report (2018). That seems like a lot, considering how instrumenting CPU time can be in the hot path for profiled code.
  • higherhalf2 hours ago
    clock_gettime() goes through vDSO, avoiding a context switch. It shows up on the flamegraph as well.
  • goodroot2 hours ago
    The QuestDB team are among the best doing it.

    Love the people and their software.

    Great blog Jaromir!

  • xthean hour ago
    This is a great example of how a small change in the right place can outweigh years of incremental tuning.
    • nomelan hour ago
      I don't think I've ever seen less than 10x speedup after putting some effort into improving performance of "organic"/legacy code. It's always shocking how slow code can be before anyone complains.
  • ee99ee3 hours ago
    This is such a great writeup