nicht angemeldet
Gunnar Bittersmann
suit
suit
suit
Gunnar Bittersmann
suit
suit
suit
Hallo,
Nachdem ich selbst feststellen musste das JQuery im IE nicht soo flüssig* läuft wie in anderen Browsern und mir das hier bestätigt wurde
.../taskspeed/report/... muss ich mir nun die Frage stellen:
MfG Tine
* Die Performance ist unzumutbar schlecht! (Schon nach einfachsten Zeilen Code)
@@Tine:
nuqneH
* Die Performance ist unzumutbar schlecht! (Schon nach einfachsten Zeilen Code)
Vielleicht verwendest du unperformante Selektoren?
Qapla'
Moin,
* Die Performance ist unzumutbar schlecht! (Schon nach einfachsten Zeilen Code)
Vielleicht verwendest du unperformante Selektoren?
Entweder ist so eine Libary eine Hilfe oder ich lasse es gleich!
Getestet habe ich einen Class-Selektor (Ich weis ID ist besser, aber es geht nun mal um einen "Group-Vorgang") wo der Firefox alles in EChtezeit erledigt und der IE eine verzögerung von jeweils 3 Sekunden pro Eingabe (...) aufweist. Einfach nur lästig dieser Grüppel von Browser!
Tine
Hi,
nach meiner Erfahrung ist jQuery das mit großem Abstand schnellste Framework seiner Art. Lediglich in Ausnahmefällen sind andere Frameworks schneller (und dann üblicherweise jeweils pro Ausnahme ein anderes).
Vielleicht verwendest du unperformante Selektoren?
Entweder ist so eine Libary eine Hilfe oder ich lasse es gleich!
Sie *ist* eine Hilfe. Bei *JEDEM* Framework bist Du jedoch für die endgültige Performance selbst verantwortlich. Nichts und niemand kann Dir dies abnehmen.
Getestet habe ich einen Class-Selektor (Ich weis ID ist besser, aber es geht nun mal um einen "Group-Vorgang") wo der Firefox alles in EChtezeit erledigt und der IE eine verzögerung von jeweils 3 Sekunden pro Eingabe (...) aufweist.
Dann machst Du etwas falsch. Selbst in umfangreichen Seiten ist selbst auf langsamen Rechnern selbst ein nicht von jQuery gecachter Select auf einen Klassenselektor signifkant schneller.
Einfach nur lästig dieser Grüppel von Browser!
Ohne Frage. Hier vermute ich das Problem aber in Deinem Code.
Cheatah
Okay..
Es hat den Anschein als ob diese Funktion alleine schon aufhält:
function checked(sel){
if ($(sel).is(":checked")){
if ($(sel).is(":disabled")) return false;
else return true;
}
else return false;
}
Ich möchte damit abfragen ob eine Checkbox gecheckt ist, aber nicht disabled.
return true or false.
das ganze wird wie folgt initiiert:
meldung(checked(sel),id,text)
Soll eine Fehlermeldung erzeugen (...) wenn checked(sel) true ergibt (...).
Wie kann ich das einfacher machen?
Sind verschachtelte Funktionsaufrufe den so verkehrt? Oder wo liegt das Problem?
Tine
function checked(sel){
if ($(sel).is(":checked")){
if ($(sel).is(":disabled")) return false;
else return true;
}
else return false;
}
Dazu brauchst du jQuery? Wenn du es performant haben willst, kannst du diese Aufgabe auch ohne "syntactic sugar" erledigen.
Was steht bei dir in sel drin? Am performantesten sind ID-Selektoren. Wenn deine Checkbox eine ID hat (macht Sinn z.B. wegen <label>), dann ist $('#id') sehr schnell.
Ohne Bibliothek (mit Ansprechen des Elements über eine ID) könnte man schreiben:
function checked (id)
var checkbox = document.getElementById(id);
if (!checkbox) return false;
return checkbox.http://de.selfhtml.org/javascript/objekte/elements.htm#checked@title=checked && !checkbox.http://de.selfhtml.org/javascript/objekte/elements.htm#disabled@title=disabled;
}
Sind verschachtelte Funktionsaufrufe den so verkehrt?
.is() ist für so etwas Unsinn, weil es die Selektor-Engine anwirft, obwohl du nur ein paar Objekteigenschaften abfragen willst. .attr() reicht hier aus. Außerdem sollte man das Suchen des Elements nicht zweimal durchführen, sondern das Ergebnis von $() (das jQuery-Objekt mit dem Knoten-Set) zwischenspeichern:
function checked (sel) {
var el = $(sel);
return el.attr('checked') && !el.attr('disabled');
}
.is() ist für so etwas Unsinn, weil es die Selektor-Engine anwirft
is() ist hier zwar nicht optimal aber durchaus noch ok. Wenngleich checked oder disabled besser geeignet sind - wie du schon sagst.
Ein durschnittlicher Sizze-Aufruf dauert im IE6 15 ms (ausgehend von SlickSpeed) - in Opera dauert er < 4 ms - natürlich sind die Zahlen auch vom Rechner abhängig.
Wenn man komplexe Selektoren verzichtet und seine Sektoren etwas optimiert dauern die aufrufe nur noch ein paar ms. Das fällt nicht wirklich ins Gewicht.
.is() ist für so etwas Unsinn, weil es die Selektor-Engine anwirft
is() ist hier zwar nicht optimal aber durchaus noch ok.
Es ist im Firefox 3.5 um den Faktor 11,5 langsamer im Vergleich zu Pure-DOM und 2,7 mal so langsam wie attr(). Das würd ich nicht als "noch ok" bezeichnen.
is() ist hier zwar nicht optimal aber durchaus noch ok.
Es ist im Firefox 3.5 um den Faktor 11,5 langsamer im Vergleich zu Pure-DOM und 2,7 mal so langsam wie attr(). Das würd ich nicht als "noch ok" bezeichnen.
Es kommt darauf an was man genau selektieren möchte. Im Fall von checked/disabled ist es aber der Overkill.
Man könnte ja direkt den Selektor verwenden um die Existenz zu prüfen und auf is() komplett verzichten.
function meldung('text', 'id') {
if('#' + id + ':checked:not(:disabled)').length > 0) {
alert('text');
}
}
Der Sinn eines Frameworks ist es ja, schneller zu Arbeiten. Die Performance ist für ein Framework imho kein Argument - da verzichte ich bewusst darauf und spare mit Zeit beim Arbeiten.
Wie Kann Ich ($(sel).is(':checked:not(:disabled)'));
hier noch verbauen?
$("#C3").click(function(event){
text = "Achtung: Fehlermeldung";
layermeldung(checked('#C3'),'#LC3',text);
});
so dass checked('#C3') direkt wegfällt?
Tine
Wie Kann Ich ($(sel).is(':checked:not(:disabled)'));
hier noch verbauen?
Meiner Meinung nach am besten gar nicht. Ich halte das weder für gut lesbar und ausdrucksstark noch ist es performant.
$("#C3").click(function(event){
text = "Achtung: Fehlermeldung";
Hier ergänzen:
var isChecked = this.checked && !this.disabled;
layermeldung(checked('#C3'),'#LC3',text);
Ersetzen durch:
layermeldung(isChecked, '#LC3', text);
});
Warum machst Du es Dir so schwer?
Struppifunction checked(sel) {
return $(sel).is(':checked:not(:disabled)');
}
Und schon wird nur noch ein Selektor ausgeführt - und auch dieser nur, um true oder false zurückzugeben.
Andererseits bleibt anzumerken, dass der IE (besonders manche ältere Version) bei Attributen von Formularelementen sehr oft eine Langsamkeit an den Tag legt, die schon an Behinderung grenzt.
Des weiteren ist es weniger hilfreich, die Funktion selbst zu übergeben. Besser wäre es da, statt der obigen Funktion innerhalb der Funktion meldung den entsprechenden Test zu machen:
function meldung(sel, id, text) {
if (!$(sel).is(':checked:not(:disabled)')) { return; }
...
}
Dazu folgender Hinweis: der IE braucht für jede Funktion, die er in seinem Stack aufbauen muss, einige Millisekunden. Wenn man also sinnvoll Funktionen vermeiden kann, ist es keine dumme Idee, dies im IE auch zu tun.
Gruß, LX
Wie kann ich das einfacher machen?
Kürzer: $(selektor).is(':checked:not(:disabled)') - damit sparst du dir zumindest ein if.
Zudem kannst du dir die Funktion "checked()" sparen, da is() ohnehin true oder false zurückgibt - also sparst du dir ein weiteres "if", zwei "else"-Zweige und eine Funktion.
meldung() scheint ebenfalls Redundanzen zu haben - wozu bekommt "meldung" eine ID UND die Prüfung für eine Checkbox übergeben? Kann Meldung nicht selbst wissen, welche Checkbox dazugehört?
Weiters: in jQuery =< 1.2.x ist es fundamentaler Unterschied ob du div#foo, div.foo, .foo oder #foo selektierst. Dieser Hinweis am Rand, nachdem du die verwendete Version verschweigst.
Ein Umstieg auf ein anderes Framework wird sich nicht auszahlen - jQuery hat eine sehr schnelle Selektor-Engine und trotzdem einen riesigen Funktionsumfang. Wie Cheatah schon sagt ist jQuery auch in Summe in puncto Performace ziemlich weit oben.
Wenn man nur die Selektor-Engine verwenden möchte ist ExtJS sicher interessanter als jQuery - das Gesamtpaket ist aber bei jQuery (+ jQuery UI) sicher wesentlich besser.
Okay.. da ich die Funktion bzw. diese Abfrage öfter brauche habe ich es nun so gelöst
function checked(sel) {
return ($(sel).is(':checked:not(:disabled)'));
}
Ist auch schon schneller.
Wie kann ich das in Zahlen sichtbar machen? Wie lange der wofür auch immer braucht?
Tine!
Hi
Wie kann ich das in Zahlen sichtbar machen? Wie lange der wofür auch immer braucht?
Firebug ist bei sowas sehr hilfreich.
Gruß
Ole
Firebug ist bei sowas sehr hilfreich.
Eigentlich nicht, da die JavaScript-Engines teilweise sehr unterschiedlich arbeiten und es ja zudem um den IE geht.
Was im Firefox schnell ist, kann den IE in die Knie zwingen und umgekehrt.
Hi
Eigentlich nicht, da die JavaScript-Engines teilweise sehr unterschiedlich arbeiten und es ja zudem um den IE geht.
ich hatte es jetzt erstmal generell auf das Messen der unterschiedlichen Funktionen bezogen....nicht auf die Browser.
Gruß
Ole
Cool Firebug läuft auch mit IETab...
Beim Manuellen messen konnte ich überigens keine Unterschiede festhalten..
Egal welche Variante ich für function checked(sel) angewendet habe ist immer eine Dif. von 15/16ms raus gekommen!
So sieht meine Funktion aus zum überprüfen:
function getms(CompareWith) {
var zeit = new Date();
var ms = zeit.getMilliseconds();
if (CompareWith != false){
alert ( ms - CompareWith);
}
return ms;
}
// How to Use..
//ms = getms(CompareWith=false); //before
//getms(CompareWith=ms); //after
Tine
lässt sich folgende Funktion zum Summieren von INPUTs vom TYPE="text" einer Klasse CLASS=".G2" noch optimieren?
function sum_sel(sel){
summe = 0;
$(sel).each(
function(){
summe = ($('#' + this.id).val()*1)+(summe*1);
}
);
return summe;
}
Tine
summe = ($('#' + this.id).val()\*1)+(summe\*1);
this sollte ausreichen '#' + this.id ist wieder mit der Kirche ums Kreuz.
dein *1 zum Typecasting ist ggf. auch etwas ruppig - hier solltest du z.B. auf parseInt() zurückgreifen.
thissollte ausreichen'#' + this.idist wieder mit der Kirche ums Kreuz.
Ah danke für den Hinweis.
dein *1 zum Typecasting ist ggf. auch etwas ruppig - hier solltest du z.B. auf parseInt() zurückgreifen.
parseInt() klappt nicht :-/
Gibt es ansonsten gar keine Alternative eine Summe zu Bilden aufgrund eines Class-Selektors? Das dauert nämlich auch sehr lange..
Tine
Ich stelle mir gerade noch die Frage welche Methode für folgendes Szenario wohl am performantesten ist. Es geht wieder um INPUT-Felder vom TYPE="TEXT" und nach jeder Eingabe soll etwas ausgeführt werden. Allerdings nicht immer das gleiche... Also hätte ich bei einer bestimmten Gruppe von INPUT-Felder die Aktion X und bei einzelnen Felder die Aktionen X,Y und Z (vereinfacht gesagt).
Jetzt stehen also 3 Methoden zur Verfügung:
Die Trigger-Variante
$(".gruppe1").keyup(function(event){ aktion_x() });
$(".gruppe2").keyup(function(event){ aktion_y() });
$("#id1").keyup(function(event){ aktion_y() });
$("#id2").keyup(function(event){ aktion_z() });
[Ungetestet]
ODER
Die OnClick-Variante
<INPUT TYPE="text" ID="A1" VALUE="123" OnClick="aktion_y();aktion_z();">
[Ungetestet]
ODER
Die If-Else-Variante mit nur einem Trigger
$("input").each(
function(){
hndl = $(this.id);
if (hndl == "id1") aktion_y();
if (hndl == "id2") aktion_x(hndl);
if (hndl == "id3") aktion_z();
}
);
[Ungetestet]
Mir geht es nur darum welche Methode am schnellsten laufen würde. Danke an alle an Dieser Stelle noch mal!
Tine!
Vorweg:
hat das etwas damit zu tun?
Mir geht es nur darum welche Methode am schnellsten laufen würde. Danke an alle an Dieser Stelle noch mal!
$('input[type=text]').[link:http://docs.jquery.com/Events/bind@title=bind](
'click keyup',
function() {
if ($('input[type=text]').[link:http://docs.jquery.com/Core/index@title=index](this) == 0) {
// do something
} else {
// do different stuff
}
}
);
Damit sparst du dir im HTML-Quelltext einiges - z.B. alle Elemente mit einer ID "durchnummerieren".
One konkrete Beschreibung des Sinns (oder zumindest deiner HTML-Strutkur) wirds aber schwierig dir zu helfen.
Ne mir gehts nur Grundsätzlich darum was Performanter wäre.
Ich kann mir gut vorstellen, dass zu viele Trigger länger brauchen, aber dem gegenüber steht ein ständiger Durchlauf von if-else abfragen was am ende evtl aufs selbe raus kommt???
Tine
Du hast meine eingangs gestellte Frage nicht beantwortet.
Ne mir gehts nur Grundsätzlich darum was Performanter wäre.
Das kommt vorrangig auf dein Dokument an. Es ist ein unterschied ob du 10 oder 10.000 input-Elemente hast.
Ich kann mir gut vorstellen, dass zu viele Trigger länger brauchen, aber dem gegenüber steht ein ständiger Durchlauf von if-else abfragen was am ende evtl aufs selbe raus kommt???
Warum sollte etwas "ständig" durchlaufen?
Wie gesagt: ohne Kenntnis deiner Dokumentstuktur ist das nicht möglich.
Du hast meine eingangs gestellte Frage nicht beantwortet.
Nein, das stammt nicht von mir. Habs mir jetzt auch nicht weiter angeschaut.
Warum sollte etwas "ständig" durchlaufen?
Also immer wenn keyup ;-)
Ich habe mal ein Beispiel vorbereitet:
Ich möchte die Summe von allen CLASS="x" aber nur von CLASS="TRa" also als Ergebis =4. Wie geht?
<TABLE>
<DIV CLASS="TRa">
<TR>
<TD><INPUT TYPE="text" CLASS="x" VALUE="1"></TD>
<TD><INPUT TYPE="text" CLASS="y" VALUE="2"></TD>
</TR>
</DIV>
<DIV CLASS="TRa">
<TR>
<TD><INPUT TYPE="text" CLASS="x" VALUE="3"></TD>
<TD><INPUT TYPE="text" CLASS="y" VALUE="4"></TD>
</TR>
</DIV>
<DIV CLASS="TRb">
<TR>
<TD><INPUT TYPE="text" CLASS="x" VALUE="5"></TD>
<TD><INPUT TYPE="text" CLASS="y" VALUE="6"></TD>
</TR>
</DIV>
</TABLE>
function sum_sel(sel){
summe = 0;
$(sel).each(
function(){
summe = $(this).val()*1+summe; // mal eins konvertiert string zu zahl
}
);
alert(summe);
}
sum_sel("?");
Tine
..Ah Sorry hab vergessen die DIVs wieder raus zu nehmen, die stammen noch von meinen Versuchen mit DIVs!
Tine
Nein, das stammt nicht von mir.
Bist du sicher?
Habs mir jetzt auch nicht weiter angeschaut.
Solltest du aber - dein Problem ist sehr verdächtig ähnlich und dort von mir schon ausreichend kommentiert.
@@suit:
nuqneH
dein *1 zum Typecasting ist ggf. auch etwas ruppig - hier solltest du z.B. auf parseInt() zurückgreifen.
AFAIR ist *1 deutlich schneller als parseInt(). Noch schneller dürfte -0 sein.
Qapla'
AFAIR ist *1 deutlich schneller als parseInt(). Noch schneller dürfte -0 sein.
mm.. gibt *-0 nicht das selbe wie *0? Nämlich 0?
Tine?
@@Tine:
nuqneH
AFAIR ist *1 deutlich schneller als parseInt(). Noch schneller dürfte -0 sein.
mm.. gibt *-0 nicht das selbe wie *0? Nämlich 0?
Hatte ich irgendwas von mit 0 multiplizieren gesagt?
Es ging darum, dass Addieren/Subtrahieren schneller sein dürfte als Multiplizieren. (Wobei der Unterschied in Prozessoren, die Multiplizieren schon intern verdrahtet haben, nicht allzu groß sein sollte.)
Qapla'
dein *1 zum Typecasting ist ggf. auch etwas ruppig - hier solltest du z.B. auf parseInt() zurückgreifen.
AFAIR ist *1 deutlich schneller als parseInt(). Noch schneller dürfte -0 sein.
Nicht unbedingt.
var test = {
parseInt: function () { var i = '100.10'; i = parseInt(i);},
parseFloat: function () { var i = '100.10'; i = parseFloat(i);},
mal: function () { var i = '100.10'; i = 1 * i;},
'null': function () { var i = '100.10'; i = i - 0 ;}
};
[link:http://javascript.jstruebig.de/javascript/368/@title=Benchmark](200000, test, function(t) {alert(t);});
FF 3.5
JS Benchmark. Anzahl der Durchläufe: 200.000
----------------------------------------
parseInt:...........265ms = 754.716/sekunde.........................
mal:................321ms = 623.052/sekunde.........................
null:...............322ms = 621.118/sekunde.........................
parseFloat:.........325ms = 615.384/sekunde.........................
OP 10
JS Benchmark. Anzahl der Durchläufe: 200.000
----------------------------------------
mal:................203ms = 985.221/sekunde.........................
null:...............234ms = 854.700/sekunde.........................
parseFloat:.........281ms = 711.743/sekunde.........................
parseInt:...........407ms = 491.400/sekunde......
IE 6
JS Benchmark. Anzahl der Durchläufe: 200.000
----------------------------------------
mal:................1297m = 154.202/sekunde.........................
null:...............1312m = 152.439/sekunde.........................
parseFloat:.........1765m = 113.314/sekunde.........................
parseInt:...........2000m = 100.000/sekunde.........................
Struppi.
@@Struppi:
nuqneH
AFAIR ist *1 deutlich schneller als parseInt(). Noch schneller dürfte -0 sein.
Nicht unbedingt.
var i = '100.10';
OK, ich war davon ausgegangen, dass im String i ein Integerwert steht. Kannst die Benchmarks nochmal mit '100' durchlaufen lassen?
Qapla'
Im Vergleich dazu, die Benchmarks mit '100', es ändert sich nicht viel, ausser das im Fx parseFloat die 2. schnellste Methode wird.
FF 3.5
JS Benchmark. Anzahl der Durchläufe: 200.000parseInt:...........265ms = 754.716/sekunde.........................
mal:................321ms = 623.052/sekunde.........................
null:...............322ms = 621.118/sekunde.........................
parseFloat:.........325ms = 615.384/sekunde.........................
JS Benchmark. Anzahl der Durchläufe: 200.000
----------------------------------------
parseInt:...........272ms = 735.294/sekunde.........................
parseFloat:.........305ms = 655.737/sekunde.........................
null:...............308ms = 649.350/sekunde.........................
mal:................316ms = 632.911/sekunde.........................
OP 10
JS Benchmark. Anzahl der Durchläufe: 200.000
mal:................203ms = 985.221/sekunde.........................
null:...............234ms = 854.700/sekunde.........................
parseFloat:.........281ms = 711.743/sekunde.........................
parseInt:...........407ms = 491.400/sekunde......
JS Benchmark. Anzahl der Durchläufe: 200.000
----------------------------------------
mal:................203ms = 985.221/sekunde.........................
null:...............219ms = 913.242/sekunde.........................
parseFloat:.........266ms = 751.879/sekunde.........................
parseInt:...........422ms = 473.933/sekunde.........................
IE 6
JS Benchmark. Anzahl der Durchläufe: 200.000
mal:................1297m = 154.202/sekunde.........................
null:...............1312m = 152.439/sekunde.........................
parseFloat:.........1765m = 113.314/sekunde.........................
parseInt:...........2000m = 100.000/sekunde.........................
JS Benchmark. Anzahl der Durchläufe: 200.000
----------------------------------------
mal:................1234m = 162.074/sekunde.........................
null:...............1250m = 160.000/sekunde.........................
parseFloat:.........1906m = 104.931/sekunde.........................
parseInt:...........2172m = 92.081/sekunde..........................
Struppi.
Der Plus-Operator (+"string") ist in der Regel am schnellsten:
http://pastebin.com/mc66191d bei 500.000 Iterationen
@@Leaky Abstraction:
nuqneH
Der Plus-Operator (+"string") ist in der Regel am schnellsten:
Wir wollen doch aber nicht zwei Strings verketten.
Qapla'
Wir wollen doch aber nicht zwei Strings verketten.
Ich rede vom unären +-Operator, nicht vom binären.
var sum = 0;
var numberInString = "100.01";
var newString = sum + numberInString;
alert(newString + "\n" + typeof newString);
var newNumber = sum + + numberInString; // beide +-Operatoren auf einmal
alert(newNumber + "\n" + typeof newNumber);
Der Plus-Operator (+"string") ist in der Regel am schnellsten:
http://pastebin.com/mc66191d
Und jetzt nochmal richtig, das erste war Number-to-Number:
http://pastebin.com/m115fe89
Da ergibt sich kein so klares Bild mehr
@@Tine:
nuqneH
Cool Firebug läuft auch mit IETab...
Ich würde Banchmarktests nicht mit einem IE als Firefox-Addon dürchführen.
Qapla'
Ich würde Banchmarktests nicht mit einem IE als Firefox-Addon dürchführen.
ACK - nichts geht über einen echten Browser unter einem "zeitgemäßen" Rechner.
Es nutzt auch nicht viel, einen IE6 zum testen auf einem nagelneuen Rechner mit Multicore-Prozessor und frischt aufgesetztem Windows zu installieren und dem IE-Prozess einen eigenen Prozessorkern zu spendieren :) Da ist das Ding vermutlich um einiges schneller als ein Firefox auf einem übermüllten System mit 20 Dragons im Hintergrund und gleichzeitiger Defragmentierung der Systemplatte :p
function checked(sel) {
return ($(sel).is(':checked:not(:disabled)'));
}
Wie LX schon sagte (ich übrigens auch): darauf kannst du verzichten, das kann doch meldung() direkt machen - damit sparst du eine Funktion ein.
Ist auch schon schneller.
Wie kann ich das in Zahlen sichtbar machen? Wie lange der wofür auch immer braucht?
Speichere die Differenz der Ausführungszeitpunkte (Anfang und Ende) in <[ref:self812;javascript/objekte/date.htm#get_milliseconds>@title=Sekunden] einzenler Funktionen (oder Codezeilen) in eine globale Variable die du dann irgendwann ausspuckst (z.B. per Alert).
Hi,
Es hat den Anschein als ob diese Funktion alleine schon aufhält:
function checked(sel){
if ($(sel).is(":checked")){
if ($(sel).is(":disabled")) return false;
else return true;
}
else return false;
}
> Ich möchte damit abfragen ob eine Checkbox gecheckt ist, aber nicht disabled.
Das würde ich gleich „an jQuery vorbei” machen:
~~~javascript
function isCheckedButNotDisabled(sel){
var elem = $(sel);
if(!elem) return false;
return elem.checked && !elem.disabled;
}
Erst noch das Element aus einem „Selektor” heraus ermitteln zu lassen, könnte man vielleicht auch noch dadurch ersetzen, dass direkt eine Elementreferenz als Übergabeparameter erwartet wird.
Jeder Aufruf einer Selektor-Funktionalität in egal welchem Framework wird immer mehr Zeit kosten - selbst wenn das Framework selber irgendwie cached - als die simple Referenz auf das zu bearbeitende Objekt, aus einer lokalen Variablen entnommen.
Frameworks verführen die Leute m.E. zu oft dazu, es mit all diesem „fancy sh^Htuff” zu übertreiben. Da bildet sich dann manch einer ein, je öfter er $(...) oder analoges benutzt, desto unabhängigere und besser wiederverwendbare Scripte würde er schreiben.
Jedes Nutztier der Gattung eierlegende Wollmilchsau verliert erheblich an Wert, wenn man es bei jeder weiteren Verwendung hinsichtlich der Performance erst mal wieder auf ein annehmbares Maß zurechtmetzgern muss, damit es den eher geringen Umfang der konkreten Einzelaufgabe zeitlich halbwegs akzeptabel hinbekommt.
MfG ChrisB
Moin,
...hinsichtlich der Performance erst mal wieder auf ein annehmbares Maß zurechtmetzgern muss, damit es den eher geringen Umfang der konkreten Einzelaufgabe zeitlich halbwegs akzeptabel hinbekommt.
Ja genau! Aber das Schlimme ist: NUR wegen dem IE! Der Firefox hat einfach keine Verzögerung von sich gegeben bei den ersten Zeilen Code und der Erste Test im IE war wie immer: "Och ne"... :-)
Tine
Hallo Tine,
die JS-Engine des IE vor Version 8 ist im Vergleich zu den modernen JS-Engines von IE8, FF3 oder gar Chrome ziemlich langsam, aber bei weitem nicht in dem von dir geschilderten Ausmaß.
Hier würde auch der Wechsel auf ein anderes Framework keinen großen Unterschied bringen, auch wenn Dojo scheinbar etwas schneller ist als jQuery (Quelle: http://blog.creonfx.com/javascript/mootools-vs-jquery-vs-prototype-vs-yui-vs-dojo-comparison-revised)
* Die Performance ist unzumutbar schlecht! (Schon nach einfachsten Zeilen Code)
Das klingt eher nach, wie Gunnar schon schrieb, unperformanten Selektoren oder generell unperformantem Code. Genaueres können wir dir leider nicht sagen, da wir deinen Code ja nicht kennen.
Ich selbst (und vermutlich auch schon viele andere) habe schon relativ aufwändige "Anwendungen" mit jQuery gebaut, die ohne (größere) Probleme auch performant in IE6+7 laufen.
Gruß
Ole
Hallo Tine,
die JS-Engine des IE vor Version 8 ist im Vergleich zu den modernen JS-Engines von IE8, FF3 oder gar Chrome ziemlich langsam, aber bei weitem nicht in dem von dir geschilderten Ausmaß.
Interessant, dass du Firefox mit Chrome auf eine Stufe stellst.
slickspeed mit jQuery 1.3.2:
78 ms: Firefox 3.5
9 ms: Chrome 3
Weitere Browser:
29 ms: Opera 10
120 ms: Internet Explorer 8
119 ms: Internet Explorer 7
619 ms: Internet Explorer 6
Man sieht deutlich, dass Firefox weit von Chrome entfernt ist - auch Opera ist deutlisch schneller. Der IE8 ist übrigens nicht so viel langsamer.
Natürlich ist das nicht die Overall-Performance, das ist klar - aber dazu finde ich grade kein entsprechendes Benchmark.