mirror of
https://github.com/9001/copyparty.git
synced 2025-08-17 09:02:15 -06:00
e3e51fb83a
file hashing became drastically slower in recent chrome versions; * 748 MiB/s in 131.0.6778.86 * 747 MiB/s in 132.0.6834.160 * 485 MiB/s in 133.0.6943.60 * 319 MiB/s in 134.0.6998.36 the silver lining: it looks like chrome-bug 1352210 is improving (crypto.subtle, the native hasher, now scales with multiple cores) * 133.0.6943.60: speed peaked at 2 threads; 341 MiB/s, 485 MiB/s * 134.0.6998.36: peak at 7; 193, 383, 383, 408, 421, 431, 438, 438 * 137.0.7151.41: peak at 8; 210, 382, 445, 513, 573, 573, 585, 598 MiB/s when hashing with 1, 2, ..., 7, 8 webworkers respectively on a ryzen7-5800x with 2x16g 2133mhz ram characteristics of versions between v134 and v137 are unknown (cannot find old official builds to test), but v137 is a good cutoff for minimizing risk of hitting chrome-bugs meanwhile, hash-wasm scales linearly up to 8 cores; 0=328 1=377 2=738 3=947 4=1090 5=1190 6=1380 7=1530 8=1810 (0 = wasm on mainthread, no webworkers) but it looks like chrome-bug 383568268 is making a return, so keep the limit of max 4 threads if machine has more than 4 cores (and numCores-1 otherwise) |
||
|---|---|---|
| .. | ||
| bench | ||
| deps-docker | ||
| docker | ||
| lics | ||
| py2/queue | ||
| pyinstaller | ||
| strip_hints | ||
| test | ||
| copyparty-android.sh | ||
| copyparty-repack.sh | ||
| fusefuzz.py | ||
| genlic.py | ||
| help2html.py | ||
| help2txt.sh | ||
| install-githooks.sh | ||
| logpack.sh | ||
| make-pypi-release.sh | ||
| make-pyz.sh | ||
| make-sfx.sh | ||
| make-tgz-release.sh | ||
| prep.sh | ||
| profile.py | ||
| rls.sh | ||
| run-tests.sh | ||
| sfx.ls | ||
| sfx.py | ||
| sfx.sh | ||
| speedtest-fs.py | ||
| tl.js | ||
| tl.py | ||
| tlcheck.sh | ||
| toc.sh | ||
| uncomment.py | ||
| ziploader.py | ||