Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unusual speed boost: size matters

webkit.org

Post reply on HN
Print view View original

21–30 of 74 posts

Re: Unusual speed boost: size matters

#21

Post by othermaciej »

cLeEOGPw wrote: post #11

It is not mentioned in the article that writing "inline" does not automatically make the function inline. It only gives C++ compiler a hint that it might be worth inlining. Compiler can inline function even if it has no inline keyword, and can not inline even when the function has the keyword, if it decides inlining would be inefficient.

In WebKit, we have macros to always inline or never inline for our target compilers, so we can force the issue if the compiler won't take the hint in a place that matters.

Re: Unusual speed boost: size matters

#23

Post by masklinn »

Others have already covered a lot of things, so I'll just say that I'm sort-of impressed by:

> The second big drop is the result of removing features and cleaning code that came from the Chromium project.

In the graph, the second big drop is ~5% of the initial code size, removing the chromium code actually reduced binary size more than the inlining fixes did.

Re: Unusual speed boost: size matters

#24

Post by kgabis »

cLeEOGPw wrote: post #11

It is not mentioned in the article that writing "inline" does not automatically make the function inline. It only gives C++ compiler a hint that it might be worth inlining. Compiler can inline function even if it has no inline keyword, and can not inline even when the function has the keyword, if it decides inlining would be inefficient.

Why does that keyword even exist then?

Re: Unusual speed boost: size matters

#25

Post by olov »

nnq wrote: post #10

looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments? this will help the optimizers a lot I imagine. and yeah, I get it that there still could be roundabout side-effects, it's not Haskell, but the compiler could just trust the programmer that he knows what he's doing when he sticks the "pure" keyword…

"Pure functions are functions which cannot access global or static, mutable state save through their arguments". http://dlang.org/function.html

Re: Unusual speed boost: size matters

#26

Post by kalleboo »

Qantourisc wrote: post #17

Or even better then double: inline void updateCachedWidth() { m_cachedWidth = computeWidth() * deviceScaleFactor(); } Ghee, was that line so hard to read ? No it's easier ! (Might have just been an example though.)

I was also wondering why this wasn't done, it must have been an example that was reduced in size.

Re: Unusual speed boost: size matters

#27

Post by nknighthb »

kgabis wrote: post #24
cLeEOGPw wrote: post #11

It is not mentioned in the article that writing "inline" does not automatically make the function inline. It only gives C++ compiler a hint that it might be worth inlining. Compiler can inline function even if it has no inline keyword, and can not inline even when the function has the keyword, if it decides inlining would be inefficient.

Why does that keyword even exist then?

Because some compilers do make use of that hint in useful ways. They're just not required to, nor are they required to do so in any specific situation, much like the register and volatile keywords.

Re: Unusual speed boost: size matters

#28

Post by moconnor »

kinlan wrote: post #3

I may have missed it, but were there any stats about the actual performance gains? It often mentioned binary size etc but nothing about the impact it had.

I cam here to say this. It's weird to talk about performance without actually showing any performance figures.

I'm all for removing old code, but if you're going to claim performance gains then why not measure those?

Re: Unusual speed boost: size matters

#29

Post by bhdz »

Sorry But I will recapture his thinking here:

    * Try to be explicit { rather than implicit }
    * Carefully consider inlining { large blocks of code }
    * Do not use static initializers { for infrequency or trivialities }

Re: Unusual speed boost: size matters

#30

Post by Someone »

nknighthb wrote: post #27
kgabis wrote: post #24

Earlier quoted context omitted.

Why does that keyword even exist then?

Because some compilers do make use of that hint in useful ways. They're just not required to, nor are they required to do so in any specific situation, much like the register and volatile keywords.

volatile is not a hint, it's a requirement. You couldn't control hardware without it (compiler: "you're only writing this variable, never reading it. I'll skip those writes to speed things up". Programmer: "why isn't my program writing anything to this I/O port?")
Post reply on HN