Skip to content

Conversation

@tromey
Copy link
Member

@tromey tromey commented Jun 15, 2016

No description provided.

@coveralls
Copy link

coveralls commented Jun 15, 2016

Coverage Status

Coverage remained the same at 20.223% when pulling 8888ca1 on tromey:fix-typo into a25e67c on fitzgen:master.

@fitzgen
Copy link
Member

fitzgen commented Jun 15, 2016

\o/

Thanks!

@fitzgen fitzgen merged commit 6024c66 into gimli-rs:master Jun 15, 2016
@tromey tromey deleted the fix-typo branch June 15, 2016 15:57
d-e-s-o added a commit to d-e-s-o/gimli that referenced this pull request Sep 10, 2025
As it turns out, the Rust compiler uses variable length LEB128 encoded
integers internally. It so happens that they spent a fair amount of
effort micro-optimizing the decoding functionality [0] [1], as it's in
the hot path.
With this change we replace our decoding routines with these optimized
ones. To make that happen more easily (and to gain some base line speed
up), also remove the "shift" return from the respective methods. As a
result of these changes, we see a respectable speed up:

System gimli-rs#1:
  Before:
    test bench_reading_leb128_unsigned  ... bench:  235.83 ns/iter (+/- 32.53)
  After:
    test bench_reading_leb128_unsigned  ... bench:  157.38 ns/iter (+/- 17.09)

System gimli-rs#2:
  Before:
    test bench_reading_leb128_unsigned  ... bench:  183.70 ns/iter (+/- 2.72)
  After:
    test bench_reading_leb128_unsigned  ... bench:  109.08 ns/iter (+/- 3.11)

[0] rust-lang/rust#69050
[1] rust-lang/rust#69157

Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o added a commit to d-e-s-o/gimli that referenced this pull request Sep 10, 2025
As it turns out, the Rust compiler uses variable length LEB128 encoded
integers internally. It so happens that they spent a fair amount of
effort micro-optimizing the decoding functionality [0] [1], as it's in
the hot path.
With this change we replace our decoding routines with these optimized
ones. To make that happen more easily (and to gain some base line speed
up), also remove the "shift" return from the respective methods. As a
result of these changes, we see a respectable speed up:

System gimli-rs#1:
  Before:
    test bench_reading_leb128_unsigned  ... bench:  235.83 ns/iter (+/- 32.53)
  After:
    test bench_reading_leb128_unsigned  ... bench:  157.38 ns/iter (+/- 17.09)

System gimli-rs#2:
  Before:
    test bench_reading_leb128_unsigned  ... bench:  183.70 ns/iter (+/- 2.72)
  After:
    test bench_reading_leb128_unsigned  ... bench:  103.83 ns/iter (+/- 3.28)

[0] rust-lang/rust#69050
[1] rust-lang/rust#69157

Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o added a commit to d-e-s-o/gimli that referenced this pull request Sep 10, 2025
As it turns out, the Rust compiler uses variable length LEB128 encoded
integers internally. It so happens that they spent a fair amount of
effort micro-optimizing the decoding functionality [0] [1], as it's in
the hot path.
With this change we replace our decoding routines with these optimized
ones. As a result of these changes, we see a respectable speed up:

System gimli-rs#1:
  Before:
    test bench_reading_leb128_unsigned  ... bench:  235.83 ns/iter (+/- 32.53)
  After:
    test bench_reading_leb128_unsigned  ... bench:  157.38 ns/iter (+/- 17.09)

System gimli-rs#2:
  Before:
    test bench_reading_leb128_unsigned  ... bench:  183.70 ns/iter (+/- 2.72)
  After:
    test bench_reading_leb128_unsigned  ... bench:  103.83 ns/iter (+/- 3.28)

[0] rust-lang/rust#69050
[1] rust-lang/rust#69157

Signed-off-by: Daniel Müller <[email protected]>
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.

3 participants