-
-
Notifications
You must be signed in to change notification settings - Fork 187
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Update file names for renumbered Ch1 sections * Chapter 1 section 3. You swapped post- and pre-! * Revert "Chapter 1 section 3. You swapped post- and pre-!" This reverts commit 5966184. * Revert "Update file names for renumbered Ch1 sections" This reverts commit 72c93d2. * Reapplied Nick's edits --------- Co-authored-by: Denis Bakhvalov <[email protected]>
- Loading branch information
1 parent
59bc1ce
commit 97c0621
Showing
1 changed file
with
5 additions
and
5 deletions.
There are no files selected for viewing
10 changes: 5 additions & 5 deletions
10
chapters/1-Introduction/1-4 What is performance analysis.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,11 @@ | ||
## What Is Performance Analysis? | ||
|
||
Have you ever found yourself debating with a coworker about the performance of a certain piece of code? Then you probably know how hard it is to predict which code is going to work the best. With so many moving parts inside modern processors, even a small tweak to the code can trigger a noticeable performance change. Some people rely on intuition when they try to optimize their applications. And usually, it ends up with random fixes here and there without making any real performance impact. | ||
Have you ever found yourself debating with a coworker about the performance of a certain piece of code? Then you probably know how hard it is to predict which code is going to work the best. With so many moving parts inside modern processors, even small tweaks to code can trigger noticeable performance changes. Relying on intuition when optimizing an application typically results in random "fixes" without real performance impact. | ||
|
||
Inexperienced developers sometimes make changes in their code and claim it *should* make it faster. One such example is replacing `i++` (pre-increment) with `++i` (post-increment) all over the code base, assuming that the previous value of `i` is not used. In the general case, this change will make no difference to the generated code because every decent optimizing compiler will recognize that the previous value of `i` is not used and will eliminate redundant copies anyway. The first piece of advice in this book is: don't solely rely on your intuition, instead *always measure*. | ||
Inexperienced developers sometimes make changes in their code and claim it *should* run faster. One such example is replacing `i++` (post-increment) with `++i` (pre-increment) all over the code base (assuming that the previous value of `i` is not used). In the general case, this change will make no difference to the generated code: every decent optimizing compiler will recognize that the previous value of `i` is not used and will eliminate redundant copies anyway. The first piece of advice in this book is: don't solely rely on your intuition. *Always measure.* | ||
|
||
Many micro-optimization tricks that circulate around the world were valid in the past, but current compilers have already learned them. Additionally, some people tend to overuse legacy bit-twiddling tricks. One such example is using [XOR-based swap idiom](https://en.wikipedia.org/wiki/XOR_swap_algorithm),[^2] while in reality, simple `std::swap` produces faster code. Such accidental changes likely won’t improve the performance of an application. Finding the right place to fix should be a result of careful performance analysis, not intuition or guessing. | ||
Many micro-optimization tricks that circulate around the world were valid in the past, but current compilers have already learned them. Additionally, some people tend to overuse legacy bit-twiddling tricks. One such example is the [XOR swap idiom](https://en.wikipedia.org/wiki/XOR_swap_algorithm).[^2] In reality, simple `std::swap` produces equivalent or faster code. Such accidental changes likely won’t improve the performance of an application. Finding the right place to tune should be the result of careful performance analysis, not intuition or guessing. | ||
|
||
Performance analysis is a process of collecting information about how a program executes and interpreting it to find optimization opportunities. Any change that ends up being made in the source code of a program should be driven by analyzing and interpreting collected data. We will show you how to use performance analysis techniques to discover optimization opportunities even in a large and unfamiliar codebase. There are many performance analysis methodologies, however, not each one of them will necessarily lead you to a discovery. With experience, you will develop your own strategy about when to use each approach. | ||
Performance analysis is a process of collecting information about how a program executes and interpreting it to find optimization opportunities. Any change that ends up being made in the source code of a program should be driven by analyzing and interpreting collected data. We will show you how to use performance analysis techniques to discover optimization opportunities even in a large and unfamiliar codebase. There are many performance analysis methodologies. Depending on the problem, some will be more efficient than others. With experience, you will develop your own strategies about when to use each approach. | ||
|
||
[^2]: XOR-based swap idiom - [https://en.wikipedia.org/wiki/XOR_swap_algorithm](https://en.wikipedia.org/wiki/XOR_swap_algorithm) | ||
[^2]: XOR-based swap idiom - [https://en.wikipedia.org/wiki/XOR_swap_algorithm](https://en.wikipedia.org/wiki/XOR_swap_algorithm) |