5 Premature optimization vs. optimizing the hot path: Decisions that impact code performance

 

This chapter covers

  • When premature optimization is evil
  • Finding the hot path in your code using performance testing and measurements
  • Optimizing the hot path

There is an old computer science saying that premature optimization is the root of all evil. This has a solid background because it’s accurate for a lot of use cases. Without any input data about expected traffic and a service level agreement (SLA), it’s hard to reason about your code and its required performance. Optimizing random paths in code in such a situation is like shooting in the dark. You will complicate your code without a sane reason.

Note

SLA specifies the amount of traffic the service should handle. It can also state the number of requests that it needs to execute and the given number of requests that must be executed with a latency lower than a specific threshold. A similar concept is nonfunctional requirements (NFR), which may specify the expected performance of a system.

5.1 When premature optimization is evil

5.1.1 Creating accounts processing pipeline

5.1.2 Optimizing processing based on false assumptions

5.1.3 Benchmarking performance optimization

5.2 Hot paths in your code

5.2.1 Understanding the Pareto principle in the context of software systems

5.2.2 Configuring the number of concurrent users (threads) for a given SLA

5.3 A word service with a potential hot path

5.3.1 Getting the word of the day

5.3.2 Validating if the word exists

5.3.3 Exposing the WordsService using HTTP service

5.4 Hot path detection in your code

5.4.1 Creating API performance tests using Gatling

5.4.2 Measuring code paths using MetricRegistry

5.5 Improvements for hot path performance