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

Enable abbreviations cache for duplicates #318

Merged
merged 1 commit into from
Jul 28, 2024

Conversation

philipc
Copy link
Contributor

@philipc philipc commented Jul 28, 2024

This speeds up the initial parsing of units when there are many small units that share abbreviations.

This was encountered for postgresql in opensuse/tumbleweed.

This speeds up the initial parsing of units when there are many
small units that share abbreviations.

This was encountered for postgresql in opensuse/tumbleweed.
@philipc philipc merged commit 983d63d into gimli-rs:master Jul 28, 2024
11 checks passed
@philipc philipc deleted the abbrev-cache branch July 28, 2024 05:23
@marxin
Copy link
Contributor

marxin commented Jul 28, 2024

How much did it improve the numbers for gimli-addr2line for the particular benchmark?

@philipc
Copy link
Contributor Author

philipc commented Jul 28, 2024

Roughly double. In the CI runs for #315, it was:

Relative speed comparison
        2.12 ±  0.02  gimli-addr2line postgres
        2.29 ±  0.04  binutils-addr2line postgres
        1.00          llvm-addr2line postgres
       24.41          elfutils-addr2line postgres

and after rebasing it improved to:

Relative speed comparison
        1.00          gimli-addr2line postgres
        2.71 ±  0.03  binutils-addr2line postgres
        1.20 ±  0.01  llvm-addr2line postgres
       29.51          elfutils-addr2line postgres

@marxin
Copy link
Contributor

marxin commented Jul 29, 2024

Nice! I can reproduce it now (I forgot to run cargo b --release after I pulled the corresponding commit)! Do you have any other interesting binaries/shared libs we can add to the benchmark script?

@philipc
Copy link
Contributor Author

philipc commented Jul 29, 2024

Probably not anything in particular that is interesting for performance reasons.

Possible things to look for are differences in things like frequency of inlined functions, use of sequences in the line table, use of shared abbreviations, size of compilation units. Some of those are going to depend on the compiler, compiler flags, or language.

What were the reasons for choosing the existing ones?

@marxin
Copy link
Contributor

marxin commented Jul 29, 2024

What were the reasons for choosing the existing ones?

Well, I basically took the biggest binaries I know of (Firefox, Clang) and then added what Mold uses for benchmarking: https://github.com/rui314/mold.

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