Dromaeo has some issues.

It is not a well balanced benchmark so it is hard to know which part are statistically relevant. Doubling the speed of Dromaeo would not double the speed of normal Web Apps.

It is also very easy to cheat on some of Dromaeo's tests. Cheating is rampant in certain engines, modern benchmarks need to perform real workload to avoid that.

Some tests of Dromaeo are great thought.

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.

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 a tool for developers, you can ignore it with mutable, const_cast, etc.

In many cases, the kind of code of the example will be optimized properly: -If the code is simple enough and all the functions are in the same compilation unit, Clang will figure out the dependencies and optimize it properly. -If the code is simple enough and the code is spread across several compilation units, Clang's link-time optimizer does an amazing job at finding dependencies.

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.

"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.