5 ms·

> Cachegrind’s output showed that the trivial methods for the simple BytePos and CharPos types in the parser are (a) extremely hot and (b) not being inlined. T

by cesarb 8y ago

> Cachegrind’s output showed that the trivial methods for the simple BytePos and CharPos types in the parser are (a) extremely hot and (b) not being inlined. To me, this points to a deficiency in the rustc compiler. All trivial methods (trivial in that they will always be cheaper than a function call) should be automatically treated by the compiler as if they had been marked #[inline]. Currently a rust programmer has to annotate every single trivial getter and setter with that attribute, which is both tiresome and easy to forget.

bluejekyll 8y ago
I’d love someone more knowledgeable to correct this, but it’s my understanding that it does inline properly inside a crate, but across crate boundaries you must mark a method as #[inline]...
- stochastic_monk 8y ago
  That sounds like using gcc for C or C++ without link-time optimization. Edit for clarification: functions not marked as inline cannot be inlined when used in another translation unit unless LTO is enabled.
- steveklabnik 8y ago
  As far as I know, that is true.
  - hobofan 8y ago
    Isn't that only true for the default "release" profile? AFAIK you have to turn LTO on, if you want to get the most performance out of it (LTO isn't on in any profile by default), but it's also been some time since I last optimized to that extent.
    - steveklabnik 8y ago
      I’m not sure to be honest, this is a corner of the language I find hard to remember.
pcwalton 8y ago
This choice came out of a desire to have some guarantees around ABI stability. The idea was that changing the body of a non-inlined, non-generic function should not require recompilation of the caller. Since then, ABI stability has been eroded for various reasons, and it may well be time to revisit this choice.
- deleted 8y ago
  [deleted]
eddyb 8y ago
We've experimented with MIR-only rlibs - https://github.com/rust-lang/rust/issues/38913#issuecomment-369584928 https://github.com/rust-lang/rust/issues/38913#issuecomment-... has some recent data on it - which seem to me like the best approach for solving this, but it needs more work. Eventually, we might compile everything at once, making the whole "crate" separation a tad bit obsolete (or even silly), other than for code organization (it has other complications, like trait coherence).

by cesarb 8y ago

bluejekyll 8y ago

I’d love someone more knowledgeable to correct this, but it’s my understanding that it does inline properly inside a crate, but across crate boundaries you must mark a method as #[inline]...

stochastic_monk 8y ago
That sounds like using gcc for C or C++ without link-time optimization. Edit for clarification: functions not marked as inline cannot be inlined when used in another translation unit unless LTO is enabled.
steveklabnik 8y ago
As far as I know, that is true.
- hobofan 8y ago
  Isn't that only true for the default "release" profile? AFAIK you have to turn LTO on, if you want to get the most performance out of it (LTO isn't on in any profile by default), but it's also been some time since I last optimized to that extent.
  - steveklabnik 8y ago
    I’m not sure to be honest, this is a corner of the language I find hard to remember.

pcwalton 8y ago

This choice came out of a desire to have some guarantees around ABI stability. The idea was that changing the body of a non-inlined, non-generic function should not require recompilation of the caller. Since then, ABI stability has been eroded for various reasons, and it may well be time to revisit this choice.

deleted 8y ago
[deleted]

eddyb 8y ago

We've experimented with MIR-only rlibs - https://github.com/rust-lang/rust/issues/38913#issuecomment-369584928 https://github.com/rust-lang/rust/issues/38913#issuecomment-... has some recent data on it - which seem to me like the best approach for solving this, but it needs more work. Eventually, we might compile everything at once, making the whole "crate" separation a tad bit obsolete (or even silly), other than for code organization (it has other complications, like trait coherence).