Lines Matching +full:very +full:- +full:high
30 Zstd uses a branch-based workflow for making changes to the codebase. Typically, zstd
51 git checkout -b <branch-name>
52 git push origin <branch-name>
57 git add -u && git commit -m <message>
58 git push origin <branch-name>
77 … to facebook:dev. You can do this very easily by clicking 'Create Pull Request' on your fork's home
113 executing it. It usually helps us find many simple bugs. Zstd uses clang's `scan-build` tool for
114 …install it by following the instructions for your OS on https://clang-analyzer.llvm.org/scan-build.
122 In general, you can use `scan-build` to static analyze any build script. For example, to static ana…
126 scan-build make -C contrib/largeNbDicts largeNbDicts
130 `scan-build` is part of our regular CI suite. Other static analyzers are not.
134 - Static analyzers are full of false positive. The signal to noise ratio is actually pretty low.
135 - A good CI policy is "zero-warning tolerance". That means that all issues must be solved, includin…
136 - Multiple static analyzers will feature multiple kind of false positives, sometimes applying to th…
139 - As if that was not enough, the list of false positives change with each version. It's hard enough…
153 re-run tests and cancel running tests from the PR page or from the respective CI's dashboard.
161 ### Third-party CI
163 For these, we use a variety of third-party services (listed below). It is not necessary to set
168 …-----------|--------------------------------------------------------------------------------------…
169 …-x86 architectures such as PowerPC | https://docs…
170 … | https://www.appveyor.com/blog/2018/10/02/github-apps-integration/ <br> h…
171 … | https://github.com/marketplace/cirrus-ci/ …
172 …ci.com/docs/2.0/getting-started/#setting-up-circleci <br> https://youtu.be/Js3hMUsSZ2c <br> https:…
181 landscape and corresponding trade-offs have been adequately analyzed, reproduced, and presented.
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
188 very well documented via past Github issues and pull requests. It may be the case that your
191 would-be PR. Of course, just because a topic has already been discussed (and perhaps rejected
194 2. The distinction between noise and actual performance gains can unfortunately be very subtle
197 take the time to run extensive, long-duration, and potentially cross-(os, platform, process, etc)
205 submitting changes that are clang-specific, windows-specific, etc.
218 Of course, benchmarking can be done on non-hyper-stable machines as well. You will just have to
239 you collect during that time period will very different from the true performance number. Having
240 a very large number of sample will help alleviate this problem slightly but you can also
245 another cpu/memory-intensive application in the background. If you are running benchmarks on your
254 …s, you can "Set Processor Affinity" using https://www.thewindowsclub.com/processor-affinity-windows
255 …pple.com/library/archive/releasenotes/Performance/RN-AffinityAPI/#//apple_ref/doc/uid/TP40006635-C…
260 4. Use a profiler with a good high resolution timer. See the section below on profiling for
269 The fastest signal you can get regarding your performance changes is via the in-build zstd cli
271 and then additionally also specify the `-b#` option. Doing this will run our benchmarking pipeline
276 very first thing you should use to asses whether you actually achieved any sort of improvement
277 is `zstd -b`. You might try to do something like this. Note: you can use the `-i` option to
282 $ git checkout <commit-before-your-change>
283 $ make && cp zstd zstd-old
284 $ git checkout <commit-after-your-change>
285 $ make && cp zstd zstd-new
286 $ zstd-old -i5 -b1 <your-test-data>
287 1<your-test-data> : 8990 -> 3992 (2.252), 302.6 MB/s , 626.4 MB/s
288 $ zstd-new -i5 -b1 <your-test-data>
289 1<your-test-data> : 8990 -> 3992 (2.252), 302.8 MB/s , 628.4 MB/s
296 obscured. So unless you see a large performance win (10-15% consistently) using just
335 $ zstd -b1 -i5 <my-data> # this will run for 5 seconds
350 you will have to supply the `-g` flag alone with your build script. You might also
351 have to provide the `-fno-omit-frame-pointer` flag
364 * Use `perf stat -r # <bench-program>` to quickly get some relevant timing and
365 counter statistics. Perf uses a high resolution timer and this is likely one
367 * Perf has a long list of hardware counters that can be viewed with `perf --list`.
371 counter `L1-dcache-load-misses`
390 The following is a non-exhaustive list of rules employed in zstd code base:
394 with 2 extensions : 64-bit `long long` types, and variadic macros.
396 Sub-project in `contrib/` are allowed to use other conventions.
406 - Reduce dependencies to the minimum possible level.
411 - Within `lib/`, this policy is even more drastic.
416 Other accepted non-symbol headers are `<stddef.h>` and `<limits.h>`.
417 - Within the project, there is a strict hierarchy of dependencies that must be respected.
423 - Functions in `lib/` must use very little stack space,
437 - `PREFIX_prefix2_camelCase`
438 - `PREFIX_camelCase_extendedQualifier`
439 * Multi-words names generally consist of an action followed by object:
440 - for example : `ZSTD_createCCtx()`
442 - `goBackward` rather than `notGoForward`
455 Any variable that can be `const` (aka. read-only) **must** be `const`.
459 …Conversely, non-const variables are a signal to readers to watch out for modifications later on in…
465 * **Assertions** are welcome, and should be used very liberally,