2016-07-09 10 views
0

Wie viel langsamer schneller ist der typeof-Operator als einen Funktionsaufruf? Oder ist es vernachlässigbar und mikrooptimierend?Mit Hilfe einer Funktion oder typeof

if (isNumber(myVar)) { 
} 

if (typeof myVar === 'number') { 
} 
+5

Testen Sie es und finden Sie es heraus? – David

+1

Ich würde nicht so viele Typprüfungen an erster Stelle durchführen. – ftor

+2

Sehen als 'isNumber' ist' undefined' und würde nur einen Fehler aus, die Zeichenfolge – adeneo

Antwort

4

Oder ist es unerheblich und Mikro-Optimierung?

Ja, das ist auf jeden Fall etwas über , wenn und nur zur Sorge, wenn Sie den Code in Frage identifizieren als eine Performance-Engpass zu sein, die wirklich unwahrscheinlich ist. Es ist Mikro-Optimierung. Funktionsaufrufe sind wirklich, wirklich schnell, auch wenn sie nicht von der JavaScript-Engine optimiert werden. Ich habe mir Sorgen über den Overhead des Funktionsaufrufs gemacht, als Array#forEach zum ersten Mal auf der Szene erschien. Schon damals, es war kein Problem, auch auf dem ältesten, langsamste JavaScript-Interpreter die ich finden konnte: Die in IE6. Details auf meinem Blog: foreach and runtime cost

Re, ob es dauert länger ... Wie lange ist ein Stück Schnur? Es hängt vollständig von der verwendeten JavaScript-Engine ab und ob der betreffende Code von der Engine als "heißer" Punkt erkannt wird (vorausgesetzt, es handelt sich um einen Engine wie V8, der in mehreren Phasen arbeitet und Hotspots optimiert).

Ein moderner Motor ist wahrscheinlich, dass Inline wenn es wichtig wird, dies zu tun. Das ist keine Garantie.

+0

In einem minimalen Fall wie diesem, können Sie ziemlich sicher sein, dass es innerhalb von ein paar Dutzend Aufrufen in jeder modernen Engine inline Funktion enthalten wird, es sei denn, Sie führen ein super trivial Skript, das es nur ein paar Mal verwendet . –

+0

@IsiahMeadows: Zitat? Ich bezweifle sehr, dass es nur ein paar Dutzend Anrufe brauchen würde (nicht dass es wirklich wichtig ist). Erinnerst du dich an den V8 Kurbelwellen Bug mit 'typeof null'? Normalerweise dauerte es Hunderte oder sogar Tausende von Aufrufen in einer engen Schleife, bevor V8 die Kurbelwelle einließ, um sie zu optimieren und den Fehler zu manifestieren. –

+0

Okay ... Ich erinnere mich wahrscheinlich nicht an die genaue Schwelle (und Sie sind richtig, dass ich ziemlich weit weg bin), aber es wird normalerweise inline, wenn der Code auf irgendeinem heißen Weg ist. –

3

Oder ist es unerheblich und Mikro-Optimierung?

Es ist vernachlässigbar und Mikro-Optimierung.


Wenn Sie etwas, das überprüfen möchten, ob eine Zahl, empfehle ich eine isNaN Prüfung und dann auf eine Zahl zu werfen.

Auf diese Weise ist es Ihnen eigentlich egal, wie der Wert als Zahl behandelt wird.

Jemand mithilfe der API kann dann wählen, um ein Objekt zu übergeben, die als Nummer behandelt werden können:

myVar = { 
    valueOf: function() { 
    return 5; 
    } 
}; 
+0

schau nicht, ob 'myVar' tatsächlich isNaN ist, wirf es einfach! Es ist so verdammt schnell, dass es egal ist, ob du es mit einer tatsächlichen Nummer machst. Und es räumt Ihren Code auf, der viel wichtiger ist. Normalerweise müssen Sie sich in Ihren Berechnungen viel mehr um echte 'NaN'-Werte kümmern, so dass mein Code normalerweise aussieht wie' myVar = + myVar || 0; ' – Thomas

+0

@Thomas Wenn Sie alle falschen automatischen Konvertierungen von Falsy-Werten vermeiden wollen, siehe [CMS-Antwort] (http://stackoverflow.com/a/1830844/1169519). – Teemu

+1

@Thomas Nein, es ist wichtiger, dass der Code korrekt ist. Mehrere Datentypen können für eine Zahl umgewandelt werden. Dies bedeutet jedoch nicht, dass es sich um eine Zahl handelt. Zum Beispiel ist eine Zeichenfolge keine Nummer. –