Dieser Artikel teilt Ihnen die Prinzipien der js-Optimierung mit. Der Inhalt ist ziemlich gut
Erstens hängt die Effizienz von JS im Gegensatz zu anderen Sprachen weitgehend von der Effizienz der JS-Engine ab. Zusätzlich zu den Vor- und Nachteilen der Engine-Implementierung übernimmt die Engine selbst auch einige Optimierungsstrategien für einige spezielle Codemuster. Beispielsweise haben die JS-Engines von FF, Opera und Safari den String-Verkettungsvorgang speziell optimiert (+). Um maximale Effizienz zu erreichen, müssen Sie natürlich das Temperament des Motors verstehen und versuchen, auf den Geschmack des Motors einzugehen. Daher ist es bei unterschiedlichen Motoren wahrscheinlich, dass die vorgenommenen Optimierungen einander zuwiderlaufen.
Und wenn Sie browserübergreifende Webprogrammierung betreiben, ist IE6 (JScript 5.6) das größte Problem! Denn ohne Hotfix führt der Garbage-Collection-Bug der JScript-Engine dazu, dass ihre Leistung in realen Anwendungen nicht in der gleichen Größenordnung liegt wie die anderer Browser. Daher ist die Optimierung in dieser Situation tatsächlich eine Optimierung für JScript!
Das erste Prinzip ist also Nur für IE6 optimieren (ungepatchtes JScript 5.6 oder früher) !
Wenn Ihr Programm auf eine akzeptable Leistung unter IE6 optimiert wurde, gibt es im Grunde keine Probleme mit der Leistung in anderen Browsern.
Bitte beachten Sie daher, dass viele der Probleme, über die ich unten spreche, bei anderen Engines möglicherweise völlig anders sind. Beispielsweise wird normalerweise davon ausgegangen, dass das Spleißen von Zeichenfolgen in einer Schleife Array.join erfordert. Aber da Engines wie SpiderMonkey die „+“-Operation für Strings optimiert haben, ist die Verwendung von Array.join nicht so effizient wie die direkte Verwendung von „+“. Betrachtet man jedoch IE6, ist dieser Effizienzunterschied zu anderen Browsern einfach nicht der Rede wert.
JS-Optimierung weist immer noch Ähnlichkeiten mit der Optimierung in anderen Sprachen auf. Beeilen Sie sich beispielsweise nicht gleich zu Beginn mit der Optimierung, denn das ist bedeutungslos. Der Schlüssel zur Optimierung liegt immer noch darin, sich auf die kritischste Stelle zu konzentrieren, nämlich den Engpass. Generell treten Engpässe immer in großen Schleifen auf. Das soll nicht heißen, dass Schleifen selbst Leistungsprobleme haben, sondern dass Schleifen mögliche Leistungsprobleme schnell verstärken können.
Das zweite Prinzip besteht also darin, groß angelegte Schleifen als Hauptoptimierungsobjekt zu verwenden.
Die folgenden Optimierungsprinzipien sind nur in großen Schleifen sinnvoll. Eine solche Optimierung außerhalb des Schleifenkörpers ist grundsätzlich sinnlos.
Derzeit werden die meisten JS-Engines interpretiert und ausgeführt. Bei der interpretierten Ausführung ist die Effizienz von Funktionsaufrufen bei allen Vorgängen gering. Darüber hinaus verringern auch zu tiefe Prototyp-Vererbungsketten oder mehrstufige Referenzen die Effizienz. In JScript beträgt der Overhead von Level-10-Referenzen etwa die Hälfte des Overheads eines leeren Funktionsaufrufs. Der Overhead beider ist viel größer als bei einfachen Operationen (z. B. vier Rechenoperationen).
Das dritte Prinzip besteht also darin, zu versuchen, übermäßige Referenzwerte und unnötige mehrfache Methodenaufrufe zu vermeiden .
Es ist wichtig zu beachten, dass es sich in einigen Fällen bei dem, was wie ein Eigenschaftszugriff aussieht, tatsächlich um einen Methodenaufruf handelt. Beispielsweise sind alle DOM-Eigenschaften tatsächlich Methoden. Beim Durchlaufen einer NodeList sieht der Zugriff der Schleifenbedingung auf nodes.length wie das Lesen von Attributen aus, entspricht jedoch tatsächlich einem Funktionsaufruf. Darüber hinaus muss bei der Implementierung von IE DOM childNodes.length jedes Mal durch interne Durchquerung neu gezählt werden. (Mein Gott, aber das ist wahr! Denn ich habe gemessen, dass die Zugriffszeit von childNodes.length proportional zum Wert von childNodes.length ist!) Das ist sehr teuer. Daher kann das vorherige Speichern von nodes.length in einer js-Variablen die Leistung der Durchquerung sicherlich verbessern.
Es ist auch ein Funktionsaufruf, und die Effizienz benutzerdefinierter Funktionen ist weitaus geringer als die von sprachintegrierten Funktionen, da letztere ein Wrapper für die nativen Methoden der Engine ist , und die Engine ist normalerweise c, Geschrieben in C++, Java. Darüber hinaus sind die Kosten für integrierte Sprachkonstrukte für dieselbe Funktion in der Regel effizienter als für integrierte Funktionsaufrufe, da erstere während der Parse-Phase des JS-Codes ermittelt und optimiert werden können.
Das vierte Prinzip besteht also darin, zu versuchen, die eigenen Konstrukte und integrierten Funktionen der Sprache zu verwenden .
Hier ist ein Beispiel für die Hochleistungsmethode String.format. Die traditionelle Implementierung von String.format besteht in der Verwendung von String.replace(regex, func). Wenn das Muster n Platzhalter enthält (einschließlich wiederholter), wird die benutzerdefinierte Funktion func n-mal aufgerufen. In dieser Hochleistungsimplementierung führt jeder Formataufruf nur einen Array.join- und dann einen String.replace(regex, string)-Vorgang aus. Beides sind integrierte Methoden der Engine ohne benutzerdefinierte Funktionsaufrufe. Zwei integrierte Methodenaufrufe und n benutzerdefinierte Methodenaufrufe, das ist der Unterschied in der Leistung.
sind ebenfalls integrierte Funktionen, es gibt jedoch immer noch Unterschiede in der Leistung. Beispielsweise ist die Zugriffsleistung von Argumenten in JScript sehr schlecht und kann fast mit einem Funktionsaufruf aufholen. Wenn daher eine einfache Funktion mit variablen Parametern zu einem Leistungsengpass wird, können Sie einige interne Änderungen vornehmen und nicht auf die Argumente zugreifen, sondern das Problem durch explizite Beurteilung der Parameter lösen.
Zum Beispiel:
Java-Code
function sum() {
var r = 0; 🎜 >
for (var i = 0; i
r += arguments[i];
} >
return
Java-Code
function sum() {
1:
Rückgabe];
2: Rückgabe Argumente[0] + Argumente[1];
Fall 3: Rückgabe Argumente[0] + Argumente[1] + Argumente[2]
> 4: return Argumente[0] + Argumente[1] + Argumente[2] + Argumente [3];
> var r = 0;
for (var i = 0; i
r += arguments[i]; >
}
Java-Code
Funktion sum(a, b, c, d, e, f, g) {
var r = a ? b ? d ? a + b + c + d + e : a + b + c : a + b : a :
0;
r;
for
(var i =}
zurück r;
}
wird deutlich verbessert (mindestens 1x schneller).
Das letzte ist das fünfte Prinzip, das in realen Anwendungen oft das wichtigste Leistungshindernis darstellt, nämlich unnötige Objekterstellung minimieren.
Die Erstellung des Objekts selbst ist mit gewissen Kosten verbunden, aber diese Kosten sind eigentlich nicht hoch. Das grundlegendste Problem besteht darin, dass JScripts extrem dämlicher Garbage-Collection-Planungsalgorithmus zu ernsthaften Leistungseinbußen führt, wenn die Anzahl der Objekte zunimmt (laut Microsoft-Leuten selbst beträgt die Komplexität O(n^2) ).
Zum Beispiel ist unser häufiges String-Splicing-Problem laut meiner Testüberprüfung überhaupt nicht die Ursache für schlechte Leistung, indem einfach mehrere String-Objekte erstellt werden. Das Schlimmste ist der Mehraufwand durch unnötige Speicherbereinigung während der Objekterstellung. Die Array.join-Methode erstellt keine Zwischenzeichenfolgenobjekte und reduziert so den verdammten Garbage-Collection-Overhead.
Wenn wir also die Erstellung großer Objekte in eine einzige Anweisung umwandeln können, wird ihre Leistung erheblich verbessert! Zum Beispiel durch die Erstellung des Codes und die anschließende Auswertung – tatsächlich arbeitet das PIES-Projekt an einem speziellen Großobjektgenerator, der auf dieser Idee basiert ...
Das ist es. Dies sind die fünf Prinzipien der JS-Optimierung, die ich zusammengefasst habe.
Neu gepostet von ---------------hax's Technologie-Blog http://hax.iteye.com/blog/126859
Verwandte Empfehlungen:
js-Optimierung funktioniert für IE6.0 (detaillierte Anordnung)_Javascript-Tipps
Das obige ist der detaillierte Inhalt vonjs-Optimierungsprinzipien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!