Lines Matching +full:libzstd +full:- +full:dev
6 New versions are being developed in the "dev" branch,
10 As a consequence, all contributions must stage first through "dev"
16 1. Fork the repo and create your branch from `dev`.
30 Zstd uses a branch-based workflow for making changes to the codebase. Typically, zstd
42 * Update your local dev branch
44 git pull https://github.com/facebook/zstd dev
45 git push origin dev
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>
71 …re sharing anything to the community, create a pull request in your own fork against the dev branch
77 … to facebook:dev. You can do this very easily by clicking 'Create Pull Request' on your fork's home
79 … * From there, select the branch where you made changes as your source branch and facebook:dev
100 the dev branch.
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…
147 series of tests when creating a PR to the dev branch and a longer series of tests
151 Most people will just want to create a PR with the destination set to their local dev
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.
184 always welcome contributions to improve performance (or worsen performance for the trade-off of
191 would-be PR. Of course, just because a topic has already been discussed (and perhaps rejected
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
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…
256 3. To benchmark, you will likely end up writing a separate c/c++ program that will link libzstd.
258 definitely some). Statically linking libzstd will be more stable. Static libraries should
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
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
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,
431 However, since `libzstd` source code can be amalgamated,
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…