Enable Link-Time Optimization (LTO) for Release builds

[zamazan4ik]

Is your feature request related to a problem? Please describe.
It's not a problem - it's an improvement idea. Improvement from the binary size and performance perspectives

Describe the solution you'd like
I noticed that in the Cargo.toml file Link-Time Optimization (LTO) for the project is not enabled. I suggest switching it on since it will reduce the binary size (always a good thing to have) and will likely improve the application's performance. If you want to read a bit more about LTO, I can recommend starting from this Rustc documentation.

I suggest enabling LTO only for the Release builds so as not to sacrifice the developers' experience while working on the project since LTO consumes an additional amount of time to finish the compilation routine. If you think that a regular Release build should not be affected by such a change as well, then I suggest adding an additional dist or release-lto profile where in addition to regular release optimizations LTO will also be added. Such a change simplifies life for maintainers and others interested in the project persons who want to build the most performant version of the package. Using ThinLTO should also help to reduce the build-time overhead with LTO - full LTO during my local tests consumed at peak 11 Gib RAM. If we enable it on the Cargo profile level, users, who build the package manually will get the LTO-optimized version "automatically". E.g., check cargo-outdated Release profile.

Basically, it can be enabled with the following lines:

[profile.release]
lto = true

According to my local tests (the latest pathway at the moment, Fedora 41, Rustc 1.83), with the command maturin build --release --strip I got the resulting wheel size reduction from 50 Mib to 43 Mib. I didn't perform performance benchmarks (at least not yet) but expect at least the same performance level (however, the CPU part of the performance should be improved as well).

Describe alternatives you've considered
N/A

Additional context
N/A

[dxtrous]

@zamazan4ik Thank you so much for taking the time to investigate LTO performance with Pathway production builds.

Assigning this enhancement for further review in the team.

[dxtrous]

Thank you for bearing with us here.
@KamilPiechowiak has investigated this question and confirmed your findings @zamazan4ik.
The LTO-built package is indeed lighter (50MB -> 43MB) and not-slower or marginally faster in benchmarks.

The issue is that the build time increases from ~2 minutes to ~30 minutes. We aim to build and tests package everywhere in the same way, and this would complicate the internal workflow (CI/CD setup. At a pure human productivity level, waiting an extra half-hour for tests to complete before merging a pull request might be problematic for our workflows.

I would propose to keep this one open, and see if we eventually figure something out.
Looping in @pw-ppodhajski as well.