- Store Emscripten cache inside node_modules/.em_cache. Docker image ships without LTO libs, so Emscripten has to rebuild stdlibs on every build otherwise.
- Merge webp_enc + webp_dec build scripts. Core libwebp library is same in both cases, so there's no point in storing and building two copies of it.
* Add LTO for C++ builds
This didn't have much effect on fastcomp builds, but provides further size savings with new LLVM backend we switched to in #750 (and fixes the MozJPEG size regression from the same PR).
In the future we won't need to pass `--llvm-lto 1` explicitly, but latest Emscripten Docker image doesn't contain the Emscripten version with the necessary fixes for this.
* Delete build.log
Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
We've been running each Make command in a single thread, resulting in fairly slow builds for C++ codecs.
This change instead runs all `make` invocations with `-j` defaulting to number of cores (retrieved via `nproc`).
On my machine Docker uses a VM configured to 4 cores out of 8 available. This change brings total build time for C++ codecs down from 10m28s to 7m5s (~3.5 minutes difference).
Note (1): I've converted imagequant builds to use built-in `make` as well to leverage this parallelisation and future-proof build script.
Note (2): we don't need to do the same for Rust, since Cargo parallelises builds by default.
Looks like we've been stuck on Emscripten fastcomp backend, misssing out on all new optimisations between LLVM 6 and LLVM 11 and going via slow asm.js pipeline when building.
This changes Docker images for Emscripten projects to point to emscripten-upstream instead and commits the updated artifacts.
This was a no-op in Wasm anyway. Now that I've added ability to control logging upstream, let's use it to disable it from compiled unit altogether for a slight win in size and perf.
This makes building simpler and allows us to potentially use multithreading version in the future.
For now points to a custom fork of OxiPNG that enables WebAssembly support, as PR is still pending review.
This intentionally excludes time of loading corresponding modules, and only measures actual processing.
While this is not perfect as it's not integrated in the UI (cc @jakearchibald), it gives at least some way to measure performance of different codecs and their integrations on particular files.
Benefits:
- newer versions of the libraries
- zlib: 1.2.8 -> 1.2.11
- libpng: 1.6.18beta04 -> 1.6.34
- much fewer dependencies to install (as libs are already in optipng archive and we don't need napa)
- much smaller build thanks to customised versions of zlib and libpng containing only APIs necessary for optipng itself: 238950 -> 177359 bytes
- much faster build thanks to preconfigured libpng and stripped APIs: 2m15s -> 40s
- much simpler build script: 77 -> 46 lines
