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