Skip to content

Conversation

@cartercanedy
Copy link

On windows, statically linking libjpeg-turbo in release builds resulted in extremely poor performance relative the system-provided shared library. Inspecting the cmake output showed that there weren't any optimization flags specified. This should fix windows-specific performance, but it's also possible that all platforms have the same behavior.

@honzasp
Copy link
Owner

honzasp commented Aug 31, 2025

Hmm, the cmake crate has some logic that should automatically pick the CMake profile from the Rust opt level:
https://docs.rs/cmake/latest/cmake/struct.Config.html#method.profile

And the TurboJPEG build guide doesn't mention that manually setting optimization flags for the compiler should be necessary, they just say that CMake should be run with -DCMAKE_BUILD_TYPE=Release:
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/BUILDING.md#visual-c-command-line

When building for x86_64-unknown-linux-gnu on my system, I verified that the build script calls cmake with -DCMAKE_BUILD_TYPE=Release and that the generated Makefiles do build the static library with -O3. I don't have access to a Windows system at the moment, can you please check where this breaks on your system? In particular, does the build script call cmake with a correct -DCMAKE_BUILD_TYPE? (You can see the cmake arguments in the output of the build script, which you can see by invoking cargo with -vv)

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