[BurntPizza]

Got to thinking: "what if that big pile of tiny functions isn't inlining as it should?"
So a few replace-regex later the local perf run says this:

Details

Not huge, but still a win, which is interesting. Want to verify with the real perf run, but I understand there's a backlog.

I didn't notice any increase in compile time or binary sizes for rustc/libs.

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

Nice find. Looks good to me if the benchmarks are corroborated.

@bors try
@Mark-Simulacrum @kennytm

⌛ Trying commit e59ea2fc56ef72b3ac332ccd28310d0662a186c0 with merge e895c391336eabdd2ec4d9f4c94a45c94f6902b0...

:)

Clearly this isn't my fault, as nobody made a lint for it!

:O

Rebased.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two #[inline]s.

@Mark-Simulacrum Could I get a perf run? Or are we waiting on making a dent in the queue?

I thought #[inline] was unnecessary on generic methods?

IIRC, ever since multiple codegen units, it can matter. I forget.

Here's the discussion I remembered: #52704

The #[inline]s on things like this and write_signed_leb128 seem definitely good, though 👍

@rust-timer build e895c391336eabdd2ec4d9f4c94a45c94f6902b0

Success: Queued e895c391336eabdd2ec4d9f4c94a45c94f6902b0 with parent 5db71db, comparison URL.

Looks like it's ready for r+

Thanks @scottmcm, I hadn't seen that thread. @alexcrichton can you tell whether any of the downsides of #[inline] would apply to these functions in libserialize? These are only intended to be called by the compiler (unlike functions in the standard library) and the perf comparison looks very good to me.

r? @alexcrichton

@dtolnay
There's probably a subset of the #[inline]s that were added that are responsible for the perf increase, and there may be a subset that is detrimental, but finding out what they are would be quite tedious, so that's why I just marked everything and tried it.

Ah yeah I explained in a bit more detail here, but none of the #[inline] on generics should be necessary but the tags pointed out by @scottmcm are likely responsible for the speedup! Could those be left and the others removed?

Thanks, we'll remove all the ones on generic functions.

r? @dtolnay

Done. I'd like to check perf again, just to be sure.

@bors try

⌛ Trying commit 1540e8c with merge 4c76652fddb127b9ed67aa60a665ab1d37f0e97f...

☀️ Test successful - status-travis
State: approved= try=True

@rust-timer build 4c76652fddb127b9ed67aa60a665ab1d37f0e97f

Success: Queued 4c76652fddb127b9ed67aa60a665ab1d37f0e97f with parent f34933b, comparison URL.

Ah-ha! Interesting. Looks too consistently worse to e noise.
cc @alexcrichton What do you make of this? Did I remove some inlines that weren't generic? Maybe there's a interaction with specialization (some of the inlines removed were on specialized functions)?
EDIT: or LLVM just actually needs the hints here.

@bors: r+

Ok I'm gonna go ahead and approve this because the functions tagged for inlining here are "obvious candidates for inlining". While it's true that not all the performance was recovered from inlining everything I think this is a good baseline to start from. I would personally prefer further analysis to figure out which functions actually need to be inlined instead of inlining all of them, which may be possible through diffing perf runs with everything inlined and without everything inlined (hottest functions at the top are likely the candidates to be inlined).

I suspect you're right in that LLVM just actually needs an extra hint for some of the functions here to inline them.

📌 Commit 1540e8c has been approved by alexcrichton

⌛ Testing commit 1540e8c with merge 9f9f2c0...

@bors retry r-