Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a very good point. You should run actual performance tests. The results may surprise you!

In my actual work, optimizing in memory searches is not worthwhile because saving half a dozen microseconds on a search is not real valuable when you are about to spend half a dozen milliseconds making a database call (which is technically O(log N), since there's a B-tree index back there). But I do spend quite a bit of time figuring out which of those queries should be moved to an in-memory O(1) cache (redis or memcache, depending).

And I actually never think about the perf tradeoff between the DB and the cache being O(log N) vs O(1) - I think of it in terms of the median and 99th %tile times that I know from monitoring our actual production servers. So as xenadu points out, I guess there is some truth in the article, but it's just sort of lost in this somewhat academic discussion of scaling things to infinity and beyond.



In my actual work, optimizing in memory searches is not worthwhile

Funnily enough, I had to do this last week. We started from the question "why does it take 160ms to scan 60,000 objects in memory?" and reached the disappointing conclusion that, on this particular platform (iMX6/800MHz/DDR3) a cache miss costs you an astonishing 233ns. I got as far as double-checking all the RAM initialisation parameters before giving up.

There is now an index on the in-memory search.


Random percentile abuse. 99% is less useful than a median. The real data is a true histogram as well as maximum time.

99% might mean every 100th customer does not get a service.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: