IE9 the new king of the Underscore performance tests

See http://documentcloud.github.com/underscore/test/test.html and past tests: http://mo.notono.us/search?q=underscore

IE9 Beta test scores against Underscore.js

Another new browser launch, and another obligatory proves-absolutely-nothing-definite/just-a-single-use-case performance test against the Underscore.js utility framework.

Previous tests showed that IE was gaining on the lead (Chrome), and that is still the case: As seen in the charts below, IE is sometimes faster, but still generally slower than Chrome (longer bars are better):

Again, this test proves very little, other than that IE9’s new Chakra JS engine is still slower than V8 for doing array iterations, and faster for mapping, getting property values, and creating list ranges.  IE9 has a number of features Chrome doesn’t have (yet) such as hardware acceleration (the IE Speed reader demo runs 790% faster in IE than in Chrome!) and ES property getter/setter standard compliance, just to mention two random ones…

IE9 beta is a HUGE step forward for IE.  Not sure if it will become my default browser, but this is at great day for the web.  Now if the EU and other governing bodies can just look the other way while MS quietly replaces all prior IE instances with IE9… ;-)

Undersore.js Performance Tests Revisited (this time with pretty charts)

Out of sheer vanity, I added my own blog feed to my Google Reader, as I was curious if anyone ever Liked my posts.
Answer: Nope. :-(

Anyhow, I came across my post on Underscore.js, and since MS just dropped Platform Preview 3 of IE 9, I thought I’d redo the comparison in Chrome6, IE8 and IE9 (though I know this is hardly any complete benchmark test, it’s still telling).  The results are below: 

As I said in my last post, I can’t wait for IE9 to replace every previous IE version…  I haven’t been this excited about an IE product since IE4, which was more than 10 years ago.

IE 8 – still a dog.

IE 9 PP3 – Starting to look good!  Faster than Chrome in some tests!

Chrome 6 – still the winner in most categories, though the lead is shrinking

Bottom line, though – if you’re doing a lot of looping/mapping, you should use Underscore rather than jQuery.

Brief GhostDoc v. 1.0.2 review

Roland Weigelt has an excellent little add-in to VS.NET, called GhostDoc. It recently won 1st price in Roy's add in contest, and it was well deserved. I downloaded it last week and tried it out on our current project, and I can see that it has great potential but falls short in a few areas. I mentioned that on Roland's blog, and he asked me for further feedback which I provided by email - but thought I'd also share here:

Mostly the method names that GhostDoc has trouble resolving are “bad” names that I had chosen. This is to be expected - it's a simple parser, not HAL - and in some cases GD actually helped point these instances out to me. But it also has problems with common composite-action styled method names like DataBind – “Datas the bind. “ wasn’t exactly what I was looking for (“Databind” works fine of course).

Where it really falls short is when I use prefixes to separate and organize methods – for example I have a common web service that exposes web methods from multiple business rule classes – in this case I use the original class name as the prefix followed by an underscore – e.g. Company_SearchParent. For this GD returns “Company_s the search parent.”

What I’d like to see is some way to set filters for (regular) expressions that GD should match, as well as filters that it should NOT match. Along with the excellent filters you have already included, that should make it capable of handling most anything (in English at least). That way I could say – exclude prefixes that end in _ so in the above example GD would just see SearchParent, which it handles quite nicely: “Searches the parent.”

Actually, come to think of it, I believe GD needs to have some special setting for underscores to handle the default names of event handlers: for example, my listDetail control has an InitializeLayout event; so VS.Net generates the method name listDetail_InitializeLayout. The expected summary of this method would be “Initializes the layout of the listDetail.” But GD generates “Lists the detail_ initialize layout.”. If GD was set to by default treat anything preceding an underscore as the indirect object of an action, that would solve both this situation and that above – I would get “Searches the parent of the Company” which is exactly what I’m doing. But some kind of regex filters would still be great…

Additionally, there needs to be user changeable settings for common terms: the term ID is one I’d like to keep as ID; i. d. looks strange to me. Similarly, an event handler’s EventArgs parameter, which VS.NET by default names e, ought to be trapped and expanded on (of course here you run into potential conflicts with Exceptions, which some people also give the name e – but that is why I use exc for Exceptions…).

Overall, this is a great tool, but I think these changes would make it even better.

Making T4MVC comply with CLS

FXCop rule CA1014 tells you to mark your assembly as CLSCompliant. If you adhere to this, your T4MVC (as of build 2.4.01 at least) will throw compiler warnings saying stuff like

Identifier

‘xxxController._Actions’ ’xxxController._Views’ ’T4MVC._Dummy’

is not CLS-Compliant.

If you have 10 controllers and 50 views this will result in 61 warnings…

The reason is that these are public members that start with an underscore, which is a CLS no-no:

http://stackoverflow.com/questions/1195030/why-is-this-name-not-cls-compliant

 

To solve this, edit the T4MVC.tt file to mark the code with a [CLSCompliant(false)] attribute.  Once you start this, you’ll also find additional warnings from mebers that implement the now-explicitly-non-compliant members, but a few more [CLSCompliant(false)] attribute handles that. Full code in gist below.

Comparative Performance of Underscore.js in Chrome and IE

I came across the very handy-looking Undersore.js today, and clicked on the test & benchmark link. I first ran the test in Chrome.  The results below show number of operations per second.  Looks like each, map, keys, values, and range are pretty inexpensive operations, whereas uniq and intersect should be used sparingly.  All makes sense. 

Then out of curiosity, I ran the same tests in IE and Firefox.  The exact numbers are not significant as the results vary by 10-20% between subsequent runs in the same browser, but the range is pretty illustrative.  And yes, I know IE9 is harder, better, faster, stronger, so this is not a fair fight.  I can’t wait for IE9 to replace every previous IE version…

	Ops/sec	(higher is	better)
Test	Chrome 6	IE 8	Firefox 3.6
_.each()	20213	510	3249
_(list).each()	13570	493	3161
jQuery.each()	3637	209	910
_.map()	18581	303	5488
jQuery.map()	7084	686	8519
_.pluck()	10852	282	4785
_.uniq()	127	1	33
_.uniq() (sorted)	308	210	84
_.sortBy()	1641	45	359
_.isEqual()	4962	869	1826
_.keys()	22675	1142	4295
_.values()	24551	321	5435
_.intersect()	83	1	20
_.range()	33345	1223	5262

Again, why I use Chrome as my default browser.