Algorithms/go-perfbook
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ramblings

Browse Source
This commit is contained in:
Damian Gryski 2018-01-20 08:40:05 -08:00
parent a01ad6ecb5
commit 93f5451295
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
performance.md
View File

@ -128,9 +128,10 @@ if performance is really important it will be a design consideration from the
start. Any significant architectural changes required to fix performance
issues will be too risky near the deadline. Note that *during* development,
the focus should be on reasonable program design, algorithms, and data
structures. Optimizing at lowel-levels of the stack should wait until later
structures. Optimizing at lower-levels of the stack should wait until later
in the development cycle when a more complete view of the system performance
is available.
is available. Any full-system profiles you do while the system is incomplete
will give a skewed view of where the bottlenecks will be in the finished system.
The difference between what your target is and the current performance will
also give you an idea of where to start. If you need only a 10%-20%
@ -292,13 +293,17 @@ sorting will pay off. On the other hand, if you're mostly doing lookups,
maybe having an array was the wrong choice and you'd be better off paying the
O(1) lookup cost for a map instead.
Choose the simplest reasonable data structure and move on. When writing a
package to be used to by others, avoid the temptation to optimize up front
for every single use case. This will result in unreadable code. Data
structures by design are effectively single-purpose. You can neither read
minds nor predict the future. If a user says "Your package is too slow for
this use case", a reasonable answer might be "Then use this other package
over here". "Do one this well."
Choose the simplest reasonable data structure and move on. CS 101, writing
"not-slow software". Don't be dumb. This should be your default development
mode.
When writing a package to be used to by others, avoid the temptation to
optimize up front for every single use case. This will result in unreadable
code. Data structures by design are effectively single-purpose. You can
neither read minds nor predict the future. If a user says "Your package is
too slow for this use case", a reasonable answer might be "Then use this
other package over here". A package should "do one this well".
Sometimes hybrid data structures will provide the performance improvement you
need. For example, by bucketing your data you can limit your search to a