write(msg)

write(msg)

A Linux blog to share any hints, tips, ebuilds, and insight I have picked up along the way. My interests mainly lie in security, photography, the web, and multimedia.

Wednesday, August 27, 2008

Tracemonkey javascript performance

I thought that my comparison of the latest Webkit vs stable Gecko wasn't fair so I decided today to create an ebuild to fetch the latest xulrunner so I could test Tracemonkey. I had to tweak the ebuild a little (other than fetching with mercurial) because xulrunner would not compile with lcms enabled. I created another USE flag that toggles lcms. With this and some modification to the patch tarball I was able to build the latest xulrunner.

Here is my ebuild:

/usr/local/portage/net-libs/xulrunner/xulrunner-9999.ebuild

This ebuild requires the xulrunner.conf from the original ebuild files.

Next I launched Epiphany and typed "about:config". I searched for "jit" and then toggled "javascript.options.jit.content" to true and restarted my browser. Then I proceeded to run Celtic Kane's javascript speed test and the Sunspider Benchmark. Celtic Kane's test didn't show much of an improvement over the old javascript engine and didn't come close to Squirrelfish's performance. The result was a paltry 23ms decrease in time.



Maybe the Sunspider Benchmark would be different. Here is the comparison of the old Gecko JS engine and Tracemonkey. The old engine is under the FROM title and Tracemonkey is under TO.



We see some significant improvements over the old engine but we see some regression too. The overall picture shows us a slight improvement. Next let's compare Webkit's results to Tracemonkey. Here we have Webkit in the TO column and Tracemonky in the FROM column. Get ready for an all out browser war!



Yikes! That's disappointing. For all the noise we've heard about Tracemonkey these were not the results I was expecting. Squirrelfish is still eating it for lunch. I guess it's a good sign that Mozilla's numbers are improving but I have yet to see the performance they claim. There could be many reasons for this and I'm sure things will only improve but as it stands now I cannot achieve the kind of numbers I've seen put up on the web about Tracemonkey.

UPDATE: Apparently JIT cannot yet be enabled in 64-bit browsers so that is why perfromance is so close between the new Tracemonkey JS engine and the old one. When that changes I'll post a real performance comparison.

Labels: , , , , , , ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

write(msg)

A Linux blog to share any hints, tips, ebuilds, and insight I have picked up along the way. My interests mainly lie in security, photography, the web, and multimedia.

Wednesday, August 27, 2008

Tracemonkey javascript performance

I thought that my comparison of the latest Webkit vs stable Gecko wasn't fair so I decided today to create an ebuild to fetch the latest xulrunner so I could test Tracemonkey. I had to tweak the ebuild a little (other than fetching with mercurial) because xulrunner would not compile with lcms enabled. I created another USE flag that toggles lcms. With this and some modification to the patch tarball I was able to build the latest xulrunner.

Here is my ebuild:

/usr/local/portage/net-libs/xulrunner/xulrunner-9999.ebuild

This ebuild requires the xulrunner.conf from the original ebuild files.

Next I launched Epiphany and typed "about:config". I searched for "jit" and then toggled "javascript.options.jit.content" to true and restarted my browser. Then I proceeded to run Celtic Kane's javascript speed test and the Sunspider Benchmark. Celtic Kane's test didn't show much of an improvement over the old javascript engine and didn't come close to Squirrelfish's performance. The result was a paltry 23ms decrease in time.



Maybe the Sunspider Benchmark would be different. Here is the comparison of the old Gecko JS engine and Tracemonkey. The old engine is under the FROM title and Tracemonkey is under TO.



We see some significant improvements over the old engine but we see some regression too. The overall picture shows us a slight improvement. Next let's compare Webkit's results to Tracemonkey. Here we have Webkit in the TO column and Tracemonky in the FROM column. Get ready for an all out browser war!



Yikes! That's disappointing. For all the noise we've heard about Tracemonkey these were not the results I was expecting. Squirrelfish is still eating it for lunch. I guess it's a good sign that Mozilla's numbers are improving but I have yet to see the performance they claim. There could be many reasons for this and I'm sure things will only improve but as it stands now I cannot achieve the kind of numbers I've seen put up on the web about Tracemonkey.

UPDATE: Apparently JIT cannot yet be enabled in 64-bit browsers so that is why perfromance is so close between the new Tracemonkey JS engine and the old one. When that changes I'll post a real performance comparison.

Labels: , , , , , , ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home