Unusual speed boost: size matters • Hacker News Board

Re: Unusual speed boost: size matters

#71

Post by BenjaminPoulain » Fri, Aug 09, 2013, 9:46 PM UTC

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.

The problem is the performance gains were measured on a patch by patch basis over a period of about a year.

Nobody kept all the numbers and digging them backwards is more work than I have time for.

I am sorry I no longer have the actual numbers. To give an idea of the order of magnitude: -For startup speed, measuring the cold start of a new WebProcess, the size of the WebCore binary seems to have a direct relation to the time it takes to start the process. Cutting 5% of binary was giving about 5% reduction of startup time. -The inlining improvements gave a runtime boost of the order of a few (single digit) percents. It was usually improvements over many benchmarks instead of being specific to one part of WebCore. -Some changes had surprising results. I don't remember specifics but some changes (unrelated to initialization) improved startup time without changing runtime performance in any measurable way.

Re: Unusual speed boost: size matters

#72

Post by huxley » Fri, Aug 09, 2013, 10:02 PM UTC

malkia wrote: post #9

CoolGuySteve wrote: post #6

Earlier quoted context omitted.

I concur. When I was there, they were pretty clear that everything I made belonged to Apple (which was total bullshit according to California law), that nothing we made would ever be open sourced due to patent issues, and that I was to never say anything about the company in public. I wonder how their team could swing that culture without tripping over legal at every turn.

Isn't WebKit based on KDE's KHTML?

Back in 2001, Apple forked KHTML and used it to create WebKit. Some parts have been backported to KHTML but the projects diverged a decade ago.

Re: Unusual speed boost: size matters

#73

Post by bzbarsky » Sat, Aug 10, 2013, 5:37 AM UTC

othermaciej wrote: post #70

bzbarsky wrote: post #45

Earlier quoted context omitted.

> and that I was to never say anything about the company > in public. This remains the case to a large extent. This makes working with Apple and Microsoft in standards groups a bit challenging at times, since they won't actually comment on whether they're even thinking about implementing a standard, or whether they would be willing to implement it as written, until they suddenly ship it. And if they're _not_ shipping…

In the case of Web standards in particular, you can usually see the checkins in our public source tree well before we ship it. But per policy we will rarely publicly commit to shipping something or not ahead of time.

Historically, the story with visibility on checkins to iOS Safari was not that great.

But yes, for desktop Safari usually one can get some idea by scouring checkin logs.

Re: Unusual speed boost: size matters

#74

Post by DannyBee » Mon, Aug 12, 2013, 5:25 PM UTC

BenjaminPoulain wrote: post #67

DannyBee wrote: post #5

the updateCachedWidth example probably gives the wrong idea to a lot of folks. You would be just as well off making computeWidth const/pure/readonly/whatever The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod/ref information and know that m_cachedWidth is not touched over that call. However, LLVM's (which is what at least Apple is using) basic stateles…

Keep in mind the example is just there to illustrate a type of problems. The real use cases were obviously more complicated. Some comments: The compiler does not do magic. If you call a virtual function or call an address from an other library, there is simply no way for the compiler to know the side effects at compile time. The keyword "const" does not help the compiler to optimize this kind of code. Const is mostly…

"Some comments: The compiler does not do magic. If you call a virtual function or call an address from an other library, there is simply no way for the compiler to know the side effects at compile time."

False. There are annotations on plenty of these libraries in header files, and you can determine virtual call side effects in plenty of cases through various forms of analysis.

"The keyword "const" does not help the compiler to optimize this kind of code. Const is mostly a tool for developers, you can ignore it with mutable, const_cast, etc."

Let's just say I understand what const and the various attributes I mentioned do, where they are useful, and how compilers use them. I disagree with your statement. Note that const where i mentioned it (IE computeWidth() const) would make the this pointer const, and const_casting that would not be legal, AFAIK.

Unless the member variable was marked as mutable, the compiler would know it is readonly.

"The point of this example was more to illustrate a point about code clarity. We should not hesitate to make code more explicit, use extra temporary variables, etc. Those extra lines help both the other hackers and the compiler."

This is not what was written in the article (though i'd agree with your statement about code clarity) , and as I showed, those extra lines do not help a good compiler.