Skip to content

Don't support DWARF 1#2

Merged
fitzgen merged 1 commit intogimli-rs:masterfrom
tromey:no-dwarf-1
Jun 15, 2016
Merged

Don't support DWARF 1#2
fitzgen merged 1 commit intogimli-rs:masterfrom
tromey:no-dwarf-1

Conversation

@tromey
Copy link
Copy Markdown
Member

@tromey tromey commented Jun 15, 2016

I think DWARF 1 was different enough that it can't be parsed by a DWARF 2+ parser. So, reject it.

@coveralls
Copy link
Copy Markdown

coveralls commented Jun 15, 2016

Coverage Status

Coverage increased (+0.3%) to 20.556% when pulling a3c6016 on tromey:no-dwarf-1 into 6024c66 on fitzgen:master.

@fitzgen fitzgen merged commit 4c8b895 into gimli-rs:master Jun 15, 2016
@fitzgen
Copy link
Copy Markdown
Member

fitzgen commented Jun 15, 2016

Gracias

@tromey tromey deleted the no-dwarf-1 branch August 19, 2016 02:29
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 <deso@posteo.net>
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 <deso@posteo.net>
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 <deso@posteo.net>
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