sorted by: recent | see : popular

Content Tagged with performance + JavaScript

Steve Souders has another insightful post where he discusses splitting the initial payload for the JavaScript in your page / application.

Steve first outlines how JavaScript can affect how the browser renders a page:

The growing adoption of Ajax and DHTML means today’s web pages have more JavaScript than ever before. The average top ten U.S. web site[1] contains 252K of JavaScript. JavaScript slows pages down. When the browser starts downloading or executing JavaScript it won’t start any other parallel downloads. Also, anything below an external script is not rendered until the script is completely downloaded and executed. Even in the case where external scripts are cached the execution time can still slow down the user experience and thwart progressive rendering.

He then took the Alexa top ten websites and tracked how much of the code was executed before the onload event, based on functions called. The results are below:

Now, it is easy to understand why this is the case. There are factors such as the simplicity in putting the code in one file, and feeling like the cache effects will make the point moot (which Steve argues against). Steve gets this:

The task of finding where to split a large set of JavaScript code is not trivial. Doloto, a project from Microsoft Research, attempts to automate this work. Doloto is not publicly available, but the paper provides a good description of their system. (You can here the creators talk about Doloto at the upcoming Velocity conference.) The approach taken by Doloto uses stub functions that download additional JavaScript on demand. This might result in users having to wait when they trigger an action that requires additional functionality. Downloading the additional JavaScript immediately after the page has rendered might result in an even faster page.

NetBeans 6.1 was just released and it is both a feature and a performance release. The feature part has to do with JavaScript support - the language everybody loves to hate (See Roberto's talk at JavaOne), MySQL improved support, Spring Framework support, Hibernate support, Axis 2, Sailfin support, and Jersey (RESTful Web Services) support.

It's also bringing back features lost in the translation from 5.5. to 6.0 such as JavaBeans support and the JSF CRUD Generator. NetBeans also now provides a more natural way to share libraries. All in all a lot of web and server-side features including support for the latest GlassFish v2ur2 release. The full list of features is here.

Performance is related to startup-time, completion speed, and memory consumption. Coming attractions include PHP support, JavaScript debugger, Groovy/Grails support, and more.

As always, the nice download matrix is available here. Congratulations to the team for yet another solid release!

Piotr Solnica did a couple of posts on jQuery and Prototype benchmarks back in the day, and John-David Dalton just found them.

In part one, he runs tests such as:

and concludes:

Executed tests show that Prototype seems to be faster then jQuery, with the exception of the new insertion method, which performance should be improved. Although I like jQuery syntax more then Prototype, the performance is way more important then saving few lines of code. Of course tests that I made don’t show how these libraries act in a real application, which is my task for the next part(s) of this article. Despite the results I must admit that I’m very excited about jQuery, my general impression is that this library is more mature then Prototype.

In part two, Piotr uses a custom JavaScript-based testing environment instead of running tests using Firebug profiler. This allows the test suite to run in many browsers, and this time concludes:

Prototype was at least 2 times faster then jQuery in 15 cases, and jQuery was faster then Prototype in 8 cases. What library should I choose? In my case I will stick with Prototype, because it offers the same functionality as jQuery does + more and it’s faster. jQuery is probably better for projects where there’s a need for some fancy UI effects and that’s it, but it’s just an assumption, correct me if I’m wrong…

Jon Davis created Using.js, a simple library to manage dependencies with the goals of:

• Seperate script dependencies from HTML markup (let the script framework figure out the dependencies it needs, not the designer)
• Make script referencing as simple and easy as possible (no need to manage the HTML files)
• Lazy load the scripts and not load them until and unless they are actually needed at runtime.

To use the script you simply:

As we see more and more tactics for getting performance by doing tricks with when scripts are loaded, I expect to see more of libraries like this. The key is working out exactly what script needs to be loaded right away, after the DOM is around, and what can wait for later. How do you want to load the script? Dynamic script element? Via iframe? XHR + eval? They all have pros and cons.

Sjoerd Mulder of Backbase ran a couple of performance tests on a slew of browsers, including IE 8 beta. He tested both the JavaScript performance, and the rendering performance:

A lot of respect and thanks to all the browser teams pushing the boundary of performance. I think it's an awesome result that the current nightlies of both Webkit and Gecko are 2x / 3x faster than the current production versions. Can't wait until Firefox 3 is released to the public!

It seems the IE team still needs to do a lot of optimization in the render engine, but still we have to consider that it's a beta 1. So let's hope they either improve some more or everybody switches to Firefox / Safari.

JavaScript Performance

The first section is the Javascript Engine of Backbase and testing various scenarios, for instance:

• TDL Compiling / parsing
• Javascript XPath 2.0 Engine
• XEL execution / event propagation

Render Performance (DOM)

The second part is rendering widgets, for example:

• Rendering 1 accordion
• Rendering 5 accordions
• Rendering a listGrid
• etc..

The full specification and timings is available to see.

Ben Lisbakken, who sits 100 feet away from me, developed gearsAJAXHelper, a library that bridges the AJAX search and feed APIs with Gears, to get a speed improvement:

We decided it would be cool to write a small library to make it easy for you AJAX APIs developers to write quick-loading, always fresh searches/feeds. The gearsAJAXHelper has two main features - it allows you to store and return key/value pairs from the local database, and it allows you to choose whether you want all resources files on the page (images, CSS, Javascript, HTML) to automatically be cached in the Gears cache.

The key/value pair database feature let's you store the query/results as a key/value pair. Then, the next time the query is made, the results can be served from the database while fresh results are being retrieved. This dramatically reduces the latency in queries/feed grabs.

The (optional) automatic cacheing of resource files will make it so that each time the user visits your webpage they will be getting resources served from their Google Gears cache, not new versions from the internet. Be careful when using this feature, as you might not want stale content to be served. There is also a refresh function, to clear the Google Gears cache of old files.

You can take a look at the sample, that saves the content for presidential candidates so if you click back on an area, you get instant loads.

The bulk of the API is:

This example shows how you can optional add super-caching to your applications with technology such as Gears. It 'aint just about offline!

NOTE: JavaScript Hackathon

If you are in the bay area, and like JavaScript (and if not, why are you on this blog!), then join us at Google this Friday for a Google Developer Hackathon focusing on JavaScript.

There will be two sessions -- one from 2:00PM - 5:30PM and another from 6:00PM - 10:00PM. You are welcome to stay for both. Please RSVP

Where: Google Campus: 1600 Amphitheatre Pkwy, Mountain View, CA 94043. It will be held in the Seville Tech Talk room.

Reposted from devphone.

Wayne Shea and Tenni Theurer have continued their performance series by delving into the iPhone and its poor little cache.

I always wonder why the cache is so small. It is typical Apple to not allow an expert mode where you can tweak it. I would rather have a few less songs and have a large cache. But, Steve knows best ;)

The end result of the article is that you should follow this ideal rule:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.

This of course is quite painful if you like to package JavaScript in One Large File for other performance reasons, or if you use a library that is larger than 25KB!

The iPhone can tell us a bunch of things about a site. If I go to TechCrunch for example, it drives me batty as it does a bunch of JavaScript to load in the CrunchBase widgets, and the iPhone keeps thinking it is loading. The blue bar keeps going, and the browser isn't as responsive. I hate those Crunchbase widgets :)

Chris Double attended the Tamarin Tech summit, and gives us some information about Tamarin Tracing the new trace based JIT experiment:

'Tamarin Tracing' is an implementation that uses a 'tracing jit'. This type of 'just in time compiler' traces code executing during hotspots and compiles it so when those hotspots are entered again the compiled code is run instead. It traces each statement executed, including within other function calls, and this entire execution path is compiled. This is different from compiling individual functions. You can gain more information for the optimizer to operate on, and remove some of the overhead of the calls. Anytime the compiled code makes a call to code that has not been jitted, the interpreter is called to continue.

Apparently the JIT for Lua is also being written using a tracing jit method and a post by Mike Pall describes the approach they are taking in some detail and lists references. A followup post provides more information and mentions Tamarin Tracing.

Brendan Eich talked about trace based JIT's as being the future of JavaScript VM's, and a reason why we will see insanely fast JavaScript without needing all of the type fun.

Here is one simple benchmark of a fibonaci equation solution that doesn't do any caching tricks:

# Turn off the tracer
$ shell/avmshell -lifespan -interp fib.abc
fib 30 = 1346269
Run time was 26249 msec = 26.25 sec
	
# Turn on the tracer
$ shell/avmshell -lifespan fib.abc
fib 30 = 1346269
Run time was 1967 msec = 1.97 sec

Chris finishes with some fun facts:

• The interpreter is written in Forth. There are .fs files in the 'core' subdirectory that contains the Forth source code. Each 'abc' bytecode is implemented in lower level instructions which are implemented in Forth. The tracing jit operates on these lower level instructions. The system can be extended with Forth code to call native C functions. The compiler from Forth to C++ is written in Python and is in 'utils/fc.py'
• The jit has two backends. One for Intel x86 32 bit, and the other for ARM. See the 'nanojit' subdirectory.
• The complete interpreter source can be rebuilt from the Forth using 'core/builtin.py'. This requires 'asc.jar' to be placed in the 'utils' subdirectory of Tamarin Tracing.