179 ## Performance  section in Contributing to Zstandard
180 Performance is extremely important for zstd and we only merge pull requests whose performance
182 This high bar for performance means that every PR which has the potential to
183 impact performance takes a very long time for us to properly review. That being said, we
184 always welcome contributions to improve performance (or worsen performance for the trade-off of
185 something else). Please keep the following in mind before submitting a performance related PR:
189 particular performance optimization has already been considered in the past. Please take some
194 2. The distinction between noise and actual performance gains can unfortunately be very subtle
201 Performance section which might be helpful for you.
202 3. Optimizing performance for a certain OS, processor vendor, compiler, or network system is a perf…
203 legitimate thing to do as long as it does not harm the overall performance health of Zstd.
207 ## Benchmarking Performance
208 Performance microbenchmarking is a tricky subject but also essential for Zstd. We value empirical
237     smaller than the performance win you are expecting.
239     you collect during that time period will very different from the true performance number. Having
255 … affinity API https://developer.apple.com/library/archive/releasenotes/Performance/RN-AffinityAPI/…
269 The fastest signal you can get regarding your performance changes is via the in-build zstd cli
292 Unless your performance win is large enough to be visible despite the intrinsic noise
296 obscured. So unless you see a large performance win (10-15% consistently) using just
304 Say you have an idea for a change that you think will provide some good performance gains
323 whose performance can be improved upon. Follow these steps to profile your code using