Skip to content

Conversation

@rugk
Copy link
Member

@rugk rugk commented Jan 31, 2026

If this is done, IMHO, we can also change the main branch, IMHO.

@rugk rugk mentioned this pull request Jan 31, 2026
@rugk
Copy link
Member Author

rugk commented Jan 31, 2026

Needed to fix the CI here now, but that seems to work. Also ran the benchmark here: https://github.com/PrivateBin/zlib-wasm-without-emscripten-sample/actions/runs/21549231403

@rugk
Copy link
Member Author

rugk commented Jan 31, 2026

Benchmark result:

> zlib-wasm-without-emscripten-sample@0.1.0 bench
> node benchmark/bench-1mbtxt.js
## lorem_1mb.txt size: 1000205
wasm x 13.24 ops/sec ±0.11% (37 runs sampled)
pako x 10.04 ops/sec ±0.25% (29 runs sampled)
native x 30.20 ops/sec ±0.63% (53 runs sampled)
Deflate: Fastest is native
## deflated lorem_1mb.txt size: 256560
wasm x 292 ops/sec ±0.81% (86 runs sampled)
pako x 177 ops/sec ±0.45% (81 runs sampled)
native x 590 ops/sec ±1.77% (87 runs sampled)
Inflate: Fastest is native
(node:2589) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

@rugk
Copy link
Member Author

rugk commented Jan 31, 2026

BTW renamed the branched and switched to main: https://github.com/PrivateBin/zlib-wasm-without-emscripten-sample

@rugk rugk enabled auto-merge January 31, 2026 18:56
@rugk rugk requested a review from elrido February 9, 2026 18:46
@elrido
Copy link

elrido commented Feb 10, 2026

I was still working on the branch to get that CI to work, but its pretty busy and I wont get back to it until the weekend after the coming one. ATM it fails badly but I don't understand why as it was still working locally on my x86 host - maybe an incompatibility of one of the used node modules with the node version used in Github actions?

I was trying to replace the node-based stuff with ancient stripped-down emscripted-"light" toolchain with an emscripten-in-a-container based workflow, so I can also use it on my aarch64 system that I use for most privatebin work these days. That requires re-writing the C-code that exposes the library functions and I hadn't yet fully grokked emscripten headers. I don't mind merging this once the CI works and once I can conclude my work I can push that as a separate branch instead of working on top of this one.

@elrido elrido self-assigned this Feb 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants