Lines Matching +full:storage +full:- +full:repo +full:- +full:branch
6 New versions are being developed in the "dev" branch,
7 or in their own feature branch.
11 or their own feature branch.
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
31 will use a new branch per sizable topic. For smaller changes, it is okay to lump multiple
32 related changes into a branch.
42 * Update your local dev branch
48 * Make a new branch on your fork about the topic you're developing for
50 # branch names should be concise but sufficiently informative
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
76 … * When you are ready to share you changes to the community, create a pull request from your branch
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…
145 that get run will depend on the destination branch you specify. Some tests take
147 series of tests when creating a PR to the dev branch and a longer series of tests
148 when creating a PR to the release branch. You can look in the configuration files
152 branch of zstd. You can then find the status of the tests on the PR's page. You can also
153 re-run tests and cancel running tests from the PR page or from the respective CI's dashboard.
159 against the main repo.
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…
263 6. Try to avoid storage. On some systems you can use tmpfs. Putting the program, inputs and outputs…
264 tmpfs avoids touching a real storage system, which can have a pretty big variability.
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,
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…