The top spot for hot topic of the week in web space deserves without doubt to go to WebAssembly.
What exactly is WebAssembly?
Now, while I am quite impressed by this project, and am pretty confident that it will be a success (the fact that Google, Mozilla and Microsoft are on board is a good guarantee), I can not help but think about how it relates to the efforts to optimize the execution speed of PHP code by the Facebook engineers.
A couple of weeks ago, Facebook held a coding marathon, together with community members, focused on improving even further the performances of real-world php applications (Drupal, Wikipedia and a handful of lucky few) when running on HHVM.
The full blog post detailing the results is at http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance. It is hugely detailed, informative and well written, I recommend it to everyone working in the PHP space.
What I found most interesting in that blog post, notwithstanding how great HHVM has become over time, is that by far, the biggest wins in terms of performance optimization were not achieved by improvements to the engine. They were achieved by patches to the application code – a fix for Drupal needlessly scanning countless directories on each invocation, and a different caching strategy for translation strings for Wikipedia.
In other words: the best way to optimize big-framework-type apps is not to have them run on a super-efficient compiler. It is to reduce the amount of useless work they do.
Architecure > Runtime
In fact, to be able to realistically measure the improvement in execution speed of Drupal, the Facebook developers even had to disable the ‘full page cache’ feature. Otherwise, by their own reckoning, they would have been benchmarking network latencies and disk IO instead of engine execution time.
Translating this for the layman: the architecture of somewhat-modern php web apps is made so that the speed of the engine is not the bottleneck in most of the cases.[footnote: this is why php7 was able to catch up quickly to HHVM and achieve huge speed gains without resorting to type inference and jit compilation. It focused on eliminating the principal bottleneck, which in the case of php was the huge amount of internal moving around of data.]
Now, every single developer in the world is happy with the more-performance-for-free thing.
But what if we try to focus on reducing the fat from the current framework-heavy development practices, every now and then?
Wasm will be used most likely by Adobe and Microsoft to deliver a web version of their productivity suites, which, come to think of it, I have already installed on my desktop, and they do work pretty well as is, at least for me.
Unexpected side effects, or: fast-food everywhere!
But having access to improved execution engines might oddly have an overall negative impact, by the fact that a lot of developers will focus less on minimizing the useless work their applications do, or on not importing huge libraries of which they use a tiny fraction.
Do we really need all-you-can-eat as web development paradigm?
Last but not least: this is my first post in the Kaliop Blog (you probably did guess that by the title already, haven’t you?). I’m very happy to have an opportunity to write here, and promise that, keeping up with the Open Source spirit of knowledge sharing, I will do my best to come up with regular posts on technical topics. Now, aren’t all of my two followers happy?
Further reading: Web Assembly