Browser Performance – 10 Year Recall


With the noticeable up-tick in blog/articles/forums entries around browser performance, coupled with the ever advancing performance improvements in the JavaScript VM space, its interesting to reflect back to some of the “old” application/framework ideas used to achieve desired performance outcomes from a user perspective.

If I recall correctly, in the Microsoft Foundation Classes (MFC)/.NET WinForm time frame, the ability to batch visual control updates using BeginUpdate() and EndUpdate() allowed software engineers to avoid certain rendering costs when making numerous changes to visual controls.  Clearly the visual control batch method wasn’t the silver bullet to make all visual performance issues disappear.  The software engineer was still required to code appropriately to batch appropriately the changes prior to making appropriate function calls onto a visual widget.

I notice there isn’t a great deal of data on optimizing web application when taking into consideration websocket’s, and streaming data.  The general web application performance articles, together with the Google I/O video presentations concentrate on JavaScript and CSS optimization, coupled with coding to leverage optimized VM features.  Clearly this is the best appropriate for a large percentage of applications.  With the ever advancing V8 VM, the browser web application world is in a much better place than a few years ago.

Back to websocket’s, and performance.  There seem to be little data around that presents a view on consumption of incoming events off a websocket, coupled with marriage of events to visual widgets.  Unsurprisingly, this again reminds me of the ways historically Java Swing/MFC/WinForm/WPF desktop applications of the “old” designed for performance.  In particular, where thread access was provided, as much work on incoming streaming data was handled by a non UI thread.  Reaching further upstream, it was not uncommon to find throttling/batching of data stream payloads to avoid flooding the user interface.

Throttling and batching in my mind provide different solution to solving the overall goal – to avoid the UI being flooded.  Throttling is usually associated with restricting the number of updates per second to a certain number, e.g 5 per second.  Throttling would normally drop certain updates outside of the throttle applied, but sill aim to ensure that the data sent from server to client within the throttle was the most up to date data.  Throttling thus offers the net out of the web application only receiving a restricted number of updates, that when applied to the

Batching is a further optimization with regards to sending data from server to client.  Specifically, if you have 10 widgets, each updating 3-7 times a second, this could mean a data payload being streamed per widget every 100mns or so, with appropriate DOM update.  Possibly a better consideration would be to batch all widget updates that are available sent in a single payload from server to client every 200mns.

What is clear is that web application development continue to move forwards in the browser space, from devtools (Canary) to JavaScript VM’s.  Firefox with OdinMonkey and Google with V8 continue to push forwards in the JS VM space, ignoring the layout engine Blink vs WebKit delta which is going to occur.  Then there’s IE11, pushing touch performance, who’s major benefit to the world might be to help eradicate old IE’s via the auto update option (following Google).

The downside of web development is still IE, as summarised by Computer World:

IE10 supports only Windows 8 and Windows 7, leaving Windows Vista stuck with IE9, just as Windows XP has been frozen at IE8.

The world will be a better place if corporations would move off Windows XP!

Final thought:  Although people appears to love tables with lots of rows, we really need to assess the ROI of the data presented, and if the all the data needs to be in the web application all the time – paging?

~ by mdavey on July 5, 2013.

One Response to “Browser Performance – 10 Year Recall”

  1. The biggest problems I have seen with websocket use and performance are:

    1. Requirements to support old IEs lead to falling back on XHR polling or JSONP, which was not meant for real-time data in the volume and speed websockets are meant to be used in financial applications. oldIE should simply not be a target browser if real-time data streaming is desired.

    2. Overuse of the websocket channel for everything, when simple request/response semantics would work much more efficiently and could proceed in parallel. This seems to be caused by relying on a single websocket framework, whether it be Nirvana or Socket.IO, to do all your client-server communication. In reality the web sockets should only be used for real-time bidirectional or server-push streaming data, which is often a very small part of the application compared to unidirectional or client-pull data requests.

    Addressing the content of your post, though: I agree that batching is quite important, and it is in this area that newer frameworks like Angular and Ember with their “run loops” really shine. They automatically perform batching on a per-event-loop-turn level, and ensure that all operations triggered by other operations within the framework end up aggregated. (See e.g. http://stackoverflow.com/questions/13597869/what-is-ember-runloop-and-how-does-it-work.) This is in contrast to something more low-level like Backbone in which you can often shoot yourself in the foot accumulating operations and reflows over multiple turns.

    If this is done correctly, combined with requestAnimationFrame for UI updates, it can obviate the need for more manual throttling of incoming server data. That is, a batched render should take less than 1/60th of a second, and if scheduled with requestAnimationFrame you can achieve buttery-smooth performance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: