Evan Martin (evan) wrote in evan_tech,
Evan Martin


A nice post about the many hoops Chromium jumps through for performance -- not in the throughput sense, but latency.

From build.chromium.org, you can click the "perf" link in the upper left to see some of the metrics we track over time. This drill-down into startup shows around r2800 we regressed startup by about 3ms, and you'd be surprised to see how much effort has been put into getting those three milliseconds back. (Normally you'd just revert the commit, but that one in particular contained about six months of work on WebKit. Large jumps on other perf graphs are related to that as well.)

Linux apparently has no way to do non-blocking IO to the disk. (Many people hear that and begin with "What about the aio/myfavoritescheme functions?" but the answer as far as I can tell is that those don't work.) It's not too hard to put disk operations on yet another thread, but it's unclear to me which parameters of a thread pool would help -- there's a trade-off between thrashing between multiple spots on the disk vs getting more data in front of the disk scheduling algorithms, etc. Anyone have anything smart to say about it?
Tags: chromium, linux

  • your vcs sucks

    I've been hacking on some Haskell stuff lately that's all managed in darcs and it's reminded me of an observation I made over two years ago now (see…

  • jaunty upgrade

    Upgraded to Ubuntu Jaunty. X hung with garbage on the screen after rebooting. Booted into "restore mode" (I forget the exact name), it gave me a…

  • ubuntu summit

    There's an Ubuntu summit going on in Mountain View next week. I'll be there Monday and plan to meet up with someone who's interested in packaging…

  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.