Real world JavaScript solution

This is the final look of the code to solve the nasty performance problems with the instant search.

if(!$.browser.msie) { /* SORRY, BUT IE IS *SLOW* WITH JQUERY */
    uls = $("#metrics ul:visible"); /* Nasty hack: */
    uls.hide();                     /* 500x speedup on Chrome */
    if(text == "") {
        $(field_search).parents(".search_realm").find(".search_item").show();
    } else {
        $(field_search).parents(".search_realm").find(".search_item[id*="+text+"]").show();
        $(field_search).parents(".search_realm").find(".search_item:not([id*="+text+"])").hide();
    }
    uls.show();
} else { /* IE SPECIFIC ALGORITHM (x10 speedup on IE) */
    $( field_search ).parents(".search_realm").find(".search_item").each(function(){
        if(this.id.indexOf(text) == -1){
            $(this).hide();
        } else {
            $(this).show();
        }
    });
}

So, what happened here?
1. The horrible, horrible Chrome performance was due to a too-early rendering attempt. Hiding the containing ul makes Chrome stop trying to render after each element "reappears" and causes no flicker on the screen. The time goes from 12000ms to ~70ms for a 1549 element set.
2. IE didn't like jQuery. Well, don't make it use jQuery. Simple, huh? ;)
Now Chrome is an absolute performance champion with times 30/70, where as IE stays in the 320's and firefox in the 300/150's.

Real world JavaScript performance mess

For a change, a post that is neither a rant nor a joke. Yes, I can hear people leaving already...

Well, I wanted to show a funny fact about JavaScript performance in a real-world case. The task is quite simple. I have a ul with 1549 (!) li elements, each with a unique id. I want to show only those whose id contains a certain substring (instant search).

For this task I have two candidates, either using jQuery selectors or "manually" filtering the list. The code is as below:

$(field_search).parents(".search_realm").find(".search_item").each(function(){
    if(this.id.indexOf(text) == -1){
        $(this).hide();
    } else {
        $(this).show();
    }
});

The jQuery option is:

$(field_search).parents(".search_realm").
            find(".search_item[id*="+text+"]").show();
$(field_search).parents(".search_realm").
            find(".search_item:not([id*="+text+"])").hide();

As you can see, it's not that complicated. Of course, suggestions accepted ;)

Now let's see the results (Hide/Show) in ms, averaged over multiple runs:

Manual         jQuery       [Browser Version]
Firefox Linux:   510/810        350/750      3.6.13
Firefox WinXP:   240/589        114/550      3.6.13
Chromium Linux: 1680/14320       35/14600    9.0.597.94
Chrome WinXP:   2340/12500       60/12600    9.0.597.107
IE7:             320/320        410/3000     7.0.5730.13

jQuery version: 1.4.4, 1.5.1 (minified)

That's right, no typos there. Weird facts:

1. Chrome is slower than firefox in 3 out of 4 cases, 2 of them being a trainwreck case.
2. Showing the previously hidden li elements takes significantly longer than the opposite except in IE7, manual method. In Chrome showing things back takes 10x more time, 500x (!) jQuery case.
3. jQuery makes it slighty faster for Firefox, variable on Chrome, slower on IE7.
4. Firefox on Windows is faster than on Linux. For Chrome results are mixed.
5. Chrome is both the best and worst performer, by an order of magnitude in both cases.
6. IE7 is capable of the fastest time to show the elements back, Chrome the slowest. Firefox is neither, but it's the best on average.

The performance fight is far from being over...

Update: In the end, after some hacks, Chrome wins the battle...

Un minijuego en 14kb... ¡de JavaScript!

Impresionante lo que hace a veces la gente para optimizar. Recuerdo cunado hace unos años vi un juego en 3D bastante resultón con un ejecutable de 96kb, llamado .kkrieger. Impresionante, pero razonable, usando ensamblador, generacion de texturas al vuelo y demás se podía dar por válido. Si uno se para a pensar, 96kb son unas 20k instrucciones, lo cual da para bastante. Si además se toma en cuenta la compresión que seguro tiene, mucho más. Aun así, era increíble ver el resultado.

Ahora la sorpresa ha venido por otro lado. Siempre he creído (y para que engañarnos, sigo creyendo) que JavaScript es un invento del demonio. Sin embargo via alt1040 he visto este juego que me ha dejado alucinando. Si ya crear imagenes con javascript es algo que jamás hubiera intentado, hacer que sea interactivo y jugable es una pasada. El autor comenta la creación en su blog, por si a alguien le interesa el "makeof". En realidad los 14kb son el resultado comprimido, pero aun así es tremendo. Si algún día necesito un dolor de cabeza me asomaré a mirar el código del invento...