Unusual speed boost: size matters

the updateCachedWidth example probably gives the wrong idea to a lot of folks.<p>You would be just as well off making computeWidth const&#x2F;pure&#x2F;readonly&#x2F;whatever<p>The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod&#x2F;ref information and know that m_cachedWidth is not touched over that call.<p>However, LLVM&#x27;s (which is what at least Apple is using) basic stateless alias analysis is not good enough to do this in this kind of case (there are some exceptions where it might be able to, none apply here)<p>This is actually a great example of how improving pointer and alias analysis in a compiler buys you gains, and <i>not</i> an example of &quot;how you should modify your code&quot;, since you generally should <i>not</i> modify your code to work around temporary single-compiler deficiencies without very good reason.<p>Especially considering how quickly compiler releases are pushed by Apple&#x2F;et al.

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.

Does anyone else find it crazy that the absolute size of WebCore is 38 MB? That&#x27;s larger than the Linux kernel which includes a bunch of drivers.<p>If I understand Webkit&#x27;s architecture correctly, that doesn&#x27;t even include chrome (the visible UI, not Google&#x27;s browser), JavaScriptCore, platform specific glue, and especially no auxilliary files (certificates, icons, the &quot;broken image&quot; sign, ...).<p>Sometimes I long for the good old days where a browser used to fit on a floppy disc (Opera).<p>I wonder if someone has done analysis on what features make browsers so complicated. I could imagine that 20% of the code could handle 80% of the features (as so often). You could have a &#x27;lite&#x27; HTML subset that&#x27;s targeted on rich documents, rather than rich client webapps. Something like that would be great for older computers or mobile computers.<p>Going a bit further, I know there is a lot of crazy stuff in WebKit... e.g. neural networks try to predict which links you&#x27;ll click on, based on previous behavior, mouse movements, etc, and then the browser prefetches likely pages. There are runtimes for NaCL, pNaCL, Flash, there&#x27;s a PDF browser (some of these are plugins), there is a VNC client, support for a bunch of different rendering models (layered HTML elements, Canvas, 3D), media support (codecs), support for webcams and microphones, and peer-to-peer communication, and much more. <i>phew</i><p>I guess a large chunk of this stuff should be in the OS, so that other apps could benefit from it. And another large part of it should be in plugins, so the browser can benefit from all the codecs on the system, for example.

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

It is not mentioned in the article that writing &quot;inline&quot; 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.

Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I&#x27;m assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.

Interesting that this article doesn&#x27;t mention profile guided optimization. In my experience, PGO is able to eliminate a lot of the performance problems associated with unnecessary inlines and rarely called functions eating up cache space.<p>The major downsides are that you can only optimize what the profiler can see and running the thing to make a build takes forever.

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

While I&#x27;m very appreciative of the contributions Apple made to the web with WebKit, most of the recent innovations and upkeep has been thanks to Google.<p>What is the future of WebKit now that Blink has been introduced? Will Apple spend considerable resources keeping an open-source project at the bleeding-edge considering it doesn&#x27;t really make them any money? Should Safari just be scrapped? It only accounts for &lt; 4% of the market share of non-mobile browsers.<p><a href="http://en.wikipedia.org/wiki/WebKit" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;WebKit</a><p><a href="http://en.wikipedia.org/wiki/Blink_(layout_engine)" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Blink_(layout_engine)</a>

I&#x27;m glad this is being discussed, because for many years inlining functions was considered a performance panacea in C++, with no regard to the size of the object code that was being generated, or the effects inlining was having on instruction cache performance.<p>The C++ community has brought itself all kinds of complexity and long compile times all in the name of performance which, in my mind, was always pretty suspect.

Sorry But I will recapture his thinking here:<p><pre><code> * Try to be explicit { rather than implicit } * Carefully consider inlining { large blocks of code } * Do not use static initializers { for infrequency or trivialities }</code></pre>

There&#x27;s a compiler optimization to automatically improve icache utilization by moving rarely executed code branches far out of line, so that they don&#x27;t take space in the loaded cache lines when the straight line code executes. (This still leaves the wasted disk space and possibly RAM)<p>GCC docs sound like the trick would be -fprofile-use, -freorder-functions and -freorder-blocks-and-partition - after a representative profiling run.<p>A representative profiling run for a shipping binary is a problem of course, JITs win here. DEC had a dynamic binary reoptimization framework in the 90s called DYNAMO that could do it for AOT compiled binaries.

Others have already covered a lot of things, so I&#x27;ll just say that I&#x27;m sort-of impressed by:<p>&gt; The second big drop is the result of removing features and cleaning code that came from the Chromium project.<p>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.

I liked this article, but the last 3 graphs were really poor. By not listing the actual binary size in some denomination of bytes for the last 3 graphs (only using %s), I get less information from the charts. A much worse problem is the date formatting, which squishes all the numbers together so that they look like one big string. The first graph was much better.

<i>Try to be explicit in your coding to help the compiler understand what you are doing.</i> - so obvious. Clarity is an evidence.)

Is webkit written in C++ instead of objective C?