4 ms·
The general process I’ve seen is to profile the application and look at what’s taking the most time. Then you sit down and think about how you could make the sl
by halpert 5y ago
The general process I’ve seen is to profile the application and look at what’s taking the most time. Then you sit down and think about how you could make the slowest parts faster. There isn’t a one-size-fits-all answer to your question. Benchmarks are good for validating your improvements, but not for finding what to improve. That’s what profiling is for.
- omginternets 5y agoYeah; this is what I meant by “banging on things with a wrench between benchmarks”. I can’t fight the feeling that there is some background knowledge that makes the search more directed.
- lossolo 5y agoThere is some background knowledge, like knowing time and space complexity of algorithms and datastructures that you use and how this abstractions interact with underlying hardware on which you are running your application. Knowing how CPU, CPU caches, OS memory management, as you mentioned that you work with Go so Go internals (like goroutines scheduling, how memory is allocated by Go runtime, how GC works etc), kernel task scheduling (context switching etc) work and how they impact your workload. A lot of it is intuition that you get with working with code that needs optimising throughout the years and a LOT of reading but sometimes you can flush that intuition into the toilet because you often find bottlenecks in places you wouldn't think about. So it really depends on the nature of your application (is it a network application or HPC, multi threaded? single threaded? distributed? you are optimising for high throughput or low latency, do you control hardware, network etc)