Enable link-time optimization for Vim in MacVim CI builds #1314
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ychin
force-pushed
the
enable-ci-link-time-optimization
branch
from
2d39f5b
to
90e91d4
Compare
ychin
changed the title
ychin
force-pushed
the
enable-ci-link-time-optimization
branch
from
6dda3eb
to
84d98cf
Compare
From local profiling, enabling LTO for Vim gives a small but measurable improvement to performance. One test that I did was to open a really large Markdown file with vim-markdown (which usually chokes at large files) installed, and measure how long that takes. With LTO turned on, usually it gives at least 6-10% performance boost, which seems significant enough to justify turning it on as we essentially get the improvement for free (I didn't see similar boosts in other benhcmarking I did though, so it depends). Slight caveat is that the binary size sees a small increase (presumably due to inlining) but it's not too much. It takes more time to build with this turned on though, so only do this in CI, for the publish builds (we don't do this for the other runs in the matrix so those runs can finish faster to provide timely feedbacks). This doesn't change the compilation/linking options for MacVim binary itself as that doesn't seem to be where performance caps are.
ychin
force-pushed
the
enable-ci-link-time-optimization
branch
2 times, most recently
from
88d7dd5
to
bca7a90
Compare
ychin
force-pushed
the
enable-ci-link-time-optimization
branch
from
bca7a90
to
491087b
Compare
They already depend on the relevant .o files, so no need to depend on the whole folder. Depending on the objects folder make them stomp each other all the time.
ychin
force-pushed
the
enable-ci-link-time-optimization
branch
from
1efc562
to
26c39df
Compare
|
On further tests, I couldn't quite find a consistent improvement with LTO, and on the tests that show them, it's pretty slight (only a couple %). Since this change seems like it would bulk up the build time from 1-2m to 15 minutes on CI, and I would need to do further changes to the Makefile to make the dependencies happy, and also the fact that LTO binaries are larger, just closing this for now. No point in needless optimization. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From local profiling, enabling LTO for Vim gives a small but measurable improvement to performance. One test that I did was to open a really large Markdown file with vim-markdown (which usually chokes at large files) installed, and measure how long that takes. With LTO turned on, usually it gives at least 4-9% performance boost, which seems significant enough to justify turning it on as we essentially get the improvement for free (I didn't see similar boosts in other benhcmarking I did though, so it depends). Slight caveat is that the binary size sees a small increase (presumably due to inlining) but it's not too much. It takes more time to build with this turned on though, so only do this in CI, for the publish builds (we don't do this for the other runs in the matrix so those runs can finish faster to provide timely feedbacks).
This doesn't change the compilation/linking options for MacVim binary itself as that doesn't seem to be where performance caps are.