4 ms·
I don't understand. Why not start with caching, then do all those things you mentioned when the site bogs down again? It'll be after all the same queries, the s
by anatoly 17y ago
I don't understand. Why not start with caching, then do all those things you mentioned when the site bogs down again? It'll be after all the same queries, the same rendering etc. post-cache; the same technique to improve them will work in the presence of cache.
So why not start with caching, especially if it buys you a large chunk of time to prepare the other stuff?
- jerf 17y agoAn uncached system is easy to understand; things happen when the code says they happen. A cached system is much more opaque when it comes to understanding performance. You want to opaquify your system after it is broadly correct, not before. "Spend" your caching dollars on the good system, not the bad one. IMHO, this is not a fundamental truth, but an accidental one. If a framework or codebase was designed from day one to avoid this effect, it might be possible to dodge this problem. But I haven't seen one really get this right yet, and I think you might have to go strongly functional to get there.
- stonemetal 17y agoBut don't you end up doing unneeded optimizations? Optimizing the heck out of something that is in the cache 99% of the time seems like a waste.
- anamax 17y agoLet's do some arithmetic. Suppose that the unoptimized computation takes 200 units, the optimized takes 100 units and a cache access takes 1 unit. With a 99% hit rate, 100 accesses will take 100 units plus the cost of 1 computation. In the unoptimized case, that's 300 units, or an average of 3 units per access. In the optimized case, that's 200 units, or an average of 2 units per case. This ignores the user-experience benefit of serving that 1 access significantly faster.