Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ExprTk #7571

Merged
merged 1 commit into from
Nov 22, 2024
Merged

Conversation

ArashPartow
Copy link
Contributor

@ArashPartow ArashPartow commented Nov 4, 2024

@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from 2a569de to 4233808 Compare November 5, 2024 10:31
@ArashPartow ArashPartow marked this pull request as draft November 10, 2024 07:08
@ArashPartow ArashPartow force-pushed the arashpartow/update_exprtk_0.0.3 branch from 6ccc786 to 19a34ce Compare November 15, 2024 22:02
@ArashPartow ArashPartow marked this pull request as ready for review November 15, 2024 22:03
@ArashPartow ArashPartow reopened this Nov 15, 2024
@Rossmaxx
Copy link
Contributor

@gnudles if you don't mind, can you brief us about the effects of updating the submodule. I'm asking you because the rest of us are clueless about the xpressive plugin infrastructure.

@gnudles
Copy link
Contributor

gnudles commented Nov 19, 2024

It is the under the hood engine that evaluates the expressions

@messmerd
Copy link
Member

Are there any plans to try to cut down on the Xpressive/exprtk binary size?

In this PR it is 66.2 MB uncompressed on Linux, while on master it is currently 70.9 MB. That's a little better, but it's still by far the largest single file in the installation after the lmms executable itself. Plus it takes longer than the other plugins to compile.

@ArashPartow
Copy link
Contributor Author

ArashPartow commented Nov 19, 2024

@messmerd a large proportion of that would be symbols et al that could be safely removed at least on Linux builds using the strip -s libxpressive.so command.

-rwxr-xr-x 1 66209040 Nov 20 10:05 libxpressive.so
-rwxr-xr-x 1 10554912 Nov 20 10:06 libxpressive_stripped.so

Might also want to do some analysis with bloaty


wrt to compilation times. It is not compilation that is slow, but rather linking. It seems that LMMS is using ye-olde ld to link. My suggestion would be to move to gold or even better yet mold or lld.

The change to the CMakeLists.txt should look something like this for linux builds:

set(CMAKE_EXE_LINKER_FLAGS -fuse-ld=gold)

Building the ExprTk test suite without and with gold:

time g++-13 -pedantic-errors -Wall -Wextra -Werror -std=c++23 -O2 -DNDEBUG -o exprtk_test exprtk_test.cpp -L/usr/lib -lstdc++

real    1m39.624s
user    1m37.630s
sys     0m1.911s


time g++-13 -pedantic-errors -Wall -Wextra -Werror -std=c++23 -O2 -DNDEBUG -o exprtk_test exprtk_test.cpp -L/usr/lib -lstdc++ -Wl,-fuse-ld=gold

real    0m42.258s
user    0m40.412s
sys     0m1.750s

@messmerd
Copy link
Member

That's great to see! I'll look into stripping the binaries and using lld or mold.

@gnudles
Copy link
Contributor

gnudles commented Nov 21, 2024

It's worth checking why the debugging symbols are there in first place.

@ArashPartow ArashPartow reopened this Nov 21, 2024
@messmerd messmerd merged commit bf54568 into LMMS:master Nov 22, 2024
27 of 31 checks passed
rubiefawn pushed a commit to rubiefawn/lmms that referenced this pull request Nov 28, 2024
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.

4 participants