| > that's a special case of the field of optimization, another mathematical discipline. I'm not sure how you can claim that the entire field of optimization is a "mathematical discipline". Algorithm analysis is, I suppose, but most other practical optimization work has little if anything to do with math. When I've spent time doing optimization work, it has often involved things like: * Discovering some API I'm using is particularly slow and finding an alternate one that's faster. * Adding caching. * Reorganizing code to take advantage of vector instructions. (Well, I haven't personally done this, but I know it's a think many others do.) * Reorganizing data to improve CPU cache usage. * Evaluating some things lazily when they aren't always needed. * Making objects smaller to put less pressure on the GC. * Inlining functions or switching some functions to macros to avoid call overhead. * Tweaking code to get some values into registers. |
The first two cases are somewhat special:
- It may be immediately obvious that an API is terrible, and that the replacement is not. If API 1 takes 1 sec to call, and API 2 takes 100ms to call, easy choice without stats.
- Caching can be dangerous. While not really a stats problem, you do need to have a really solid model of what is getting cached, and how to know when to invalidate those cache entries.
For the rest of the examples you provided, you're making changes that may make the problem better, may have no effect, or may make the problem worse. You absolutely need to use statistics to determine whether or not changes like those are actually having an effect. Performance analysis is part math and part art, and without the math background, you're likely going to be spinning your wheels a bunch. Beyond stats, fields like queuing theory are going to make a huge impact when you're doing performance optimization in distributed systems.