Hi Greg, > v9, attached, is what my last email described.
Thanks, and no worries about v8. I went through v9 on my side, on 0f3b42ce806 with zstd 1.5.7: - All four patches apply cleanly with git am. There are no compiler warnings at -O2 or under cassert+ASan, and make check passes in both (241 tests, compression_zstd and compression_zstd_dict included), as does contrib/amcheck. - 0003 carries the context reuse as I sent it, only with a longer comment above it, and with my name on it. Thanks for that. > I ran repro-dctx-reset.sh unchanged against v9 and against v9 > with the ZSTD_DCtx_reset() call removed I get the same here. v9 passes, B2 included, with exactly the three expected "compressed zstd data is corrupt" errors, nothing else, and no ASan reports. With only the reset removed, B2 comes back with wrong data and no error while A2, A3 and B3 stay true, and the slices of good values after an error fail instead (9 errors where 3 are expected). I also re-ran the timings on v9 against v9 with the reuse undone (the v7 decompression code): three independent runs, 38 paired rounds in all, hot cache, each round checked against an idle CPU calibration and none discarded. Median ratio over the 38 rounds, with the range covered by the three runs' 95% CIs; below 1 means v9 is faster: - 32 kB slice: docs 0.739 [0.694, 0.749], json 0.648 [0.598, 0.653], random 0.741 [0.696, 0.752] - 32 kB prefix: docs 0.747 [0.702, 0.754], json 0.701 [0.653, 0.709], random 0.761 [0.714, 0.789] - 32 kB full read: docs 0.887 [0.828, 0.890], random 0.872 [0.822, 0.880]; json 1.000 [0.988, 1.006] - 1 MB random slice: 0.694 [0.686, 0.703] - 4 kB slice: 0.943 to 0.978 across the three corpora - load, i.e. compression, which the reuse does not touch: 0.988 to 0.998, every range containing 1 All the slices, the 32 kB prefixes and the docs and random 32 kB full reads were faster in each of the 38 rounds. One small thing in the 0003 commit message: "slices and prefixes of 4kB-32kB values take about 40% less time" is more than I see. Here it is 24-35% less at 32 kB and 2-6% at 4 kB, so maybe "about 25-35% less time for 32 kB values, a few percent at 4 kB", unless your hosts show otherwise. I also see that the XXX on the dictionary prefix path in 0004 now mentions the reset it would need if it moved to the streaming loop. My checks don't exercise dictionaries, so I have nothing to add there. I can share the scripts and the per-run numbers if that is useful. Regards, Manu
