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 Engines am wahrscheinlichsten, dass die vorgenommenen Optimierungen gegensätzlich sind.
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 besteht also darin, nur für IE6 (ungepatchtes JScript 5.6 oder früher) zu optimieren!
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ße 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 viele Referenzebenen und unnötige Mehrfachaufrufe von Methoden 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-Attribute 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 für die gleiche Funktion die Kosten für integrierte Sprachkonstrukte 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 Konstrukte und integrierten Funktionen der Sprache selbst 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 < arguments.length; i++) {
r += arguments[i];
}
return r;
}Nach dem Login kopieren
Diese Summe wird normalerweise mit einer kleinen Anzahl von Parametern aufgerufen, und wir hoffen, ihre Leistung zu verbessern, wenn weniger Parameter vorhanden sind. Bei Änderung in:
Java-Code
function sum() {
switch (arguments.length) {
case 1: return arguments[0];
case 2: return arguments[0] + arguments[1];
case 3: return arguments[0] + arguments[1] + arguments[2];
case 4: return arguments[0] + arguments[1] + arguments[2] + arguments[3];
default:
var r = 0;
for (var i = 0; i < arguments.length; i++) {
r += arguments[i];
}
return r;
}
}Nach dem Login kopieren
Tatsächlich wird es nicht viel besser werden, aber wenn es geändert wird in:
Java代码
function sum(a, b, c, d, e, f, g) {
var r = a ? b ? c ? d ? e ? f ? a + b + c + d + e + f : a + b + c + d + e : a + b + c + d : a + b + c : a + b : a : 0;
if (g === undefined) return r;
for (var i = 6; i < arguments.length; i++) {
r += arguments[i];
}
return r;
}Nach dem Login kopieren
就会提高很多（至少快1倍）。
最后是第五原则，也往往是真实应用中最重要的性能障碍，那就是尽量减少不必要的对象创建。
本身创建对象是有一定的代价的，但是这个代价其实并不大。最根本的问题是由于JScript愚蠢之极的垃圾回收调度算法，导致随着对象个数的增加，性能严重下降（据微软的人自己说复杂度是O(n^2)）。
比如我们常见的字符串拼接问题，经过我的测试验证，单纯的多次创建字符串对象其实根本不是性能差的原因。要命的是在对象创建期间的无谓的垃圾回收的开销。而Array.join的方式，不会创建中间字符串对象，因此就减少了那该死的垃圾回收的开销。
因此，如果我们能把大规模对象创建转化为单一语句，则其性能会得到极大的提高！例如通过构造代码然后eval——实际上PIES项目中正在根据这个想法来做一个专门的大规模对象产生器……
好了上面就是总结的JS优化五大原则。
Das obige ist der detaillierte Inhalt vonFassen Sie die fünf wichtigsten JavaScript-Optimierungsprinzipien zusammen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
