JavaScript Tempo

[Rolf b]

Hallo Experten,

ich mag mich nicht wiederholen, darum verlinke ich mich einfach selbst: http://stackoverflow.com/questions/37092820/strange-performance-behavior-in-javascript

Hat von euch einer eine Idee?

Gruß Rolf

[dedlfix]

Tach!

ich mag mich nicht wiederholen, darum verlinke ich mich einfach selbst: http://stackoverflow.com/questions/37092820/strange-performance-behavior-in-javascript

Ich kann dich leider nicht erleuchten.

Hat von euch einer eine Idee?

Aber eine Idee habe ich, und zwar in eine ganz andere Richtung. Warum genau möchtest du denn die Ausführungszeit von 10 Millionen Zugriffen messen? Hast du einen Anwendungsfall, beim dem eine solch hohe Zahl vorkommt? Oder ist das lediglich die Messung einer ansonsten völlig vernachlässigbaren Dauer, die, um sie überhaupt übers Grundrauschen zu bekommen, in einer so wahnsinnig hohen Zahl an Wiederholungen ausgeführt werden muss?

Ich meine, es ist ja legitim, sich Gedanken darum zu machen, ob die eine oder andere Vorgehensweise performant ist oder nicht. Aber oftmals fällt das in die Kategorie Mikrooptimierung, gepaart mit dem Adjektiv „unnötige“. Vor allem dann, wenn man im zu erwartenden Anwendungsszenario nur eine Handvoll Zugriffe hat, die nicht weiter spürbar sind. Die Zeit, die bei derartigen Überlegungen draufgeht, ist besser in die Formulierung verständlichen Codes investiert.

dedlfix.

[Rolf b]

Hallo dedlfix,

natürlich hast Du recht, wenn Du hier von Mikrooptimierung sprichst. Ich überarbeite den Einführungsartikel zu Objekten, und gehe dort auf die unterschiedlichen Arten ein, Properties zu erzeugen. Wenn es unterschiedliche Arten gibt, dann sollte man auch auf Vor- und Nachteile eingehen. Und dafür wollte ich ein Gefühl für die Verarbeitungsgeschwindigkeit bekommen. Wenn jeder Propertyzugriff 20 mal so lange dauert, und ich intensive Verarbeitung betreibe, kann es schon wichtig sein ob man seine Objekte grundsätzlich auf die eine oder andere Art konstruiert. Und dabei bin ich dann auf dieses merkwürdige Chrome-Phänomen gestoßen.

Das Phänomen geht übrigens fast weg, wenn man im Konstruktor ein Symbol anlegt und dem Objekt ein Property gibt, das über dieses Symbol angesprochen wird. Hier auf meinem Büro-PC fällt die Laufzeit dann von 1900ms auf 220ms. Nur durch das Hinzufügen eines Symbol-Properties, ohne es in der Messschleife anzufassen. Sehr merkwürdig.

Gruß Rolf

[dedlfix]

Tach!

natürlich hast Du recht, wenn Du hier von Mikrooptimierung sprichst. Ich überarbeite den Einführungsartikel zu Objekten, und gehe dort auf die unterschiedlichen Arten ein, Properties zu erzeugen. Wenn es unterschiedliche Arten gibt, dann sollte man auch auf Vor- und Nachteile eingehen. Und dafür wollte ich ein Gefühl für die Verarbeitungsgeschwindigkeit bekommen. Wenn jeder Propertyzugriff 20 mal so lange dauert, und ich intensive Verarbeitung betreibe, kann es schon wichtig sein ob man seine Objekte grundsätzlich auf die eine oder andere Art konstruiert.

Klingt zunächst legitim. Aber du kannst nicht nur einmal die Geschwindigkeit messen und das dann in Stein meißeln. Es gibt ja nicht nur eine Javascript-Engine, jede optimiert anders als die anderen, und sie entwickeln sich weiter. Willst du mit jeder Engine einzeln messen und mit jeder Version die Messungen wiederholen und den Artikel anpassen? Und ist das wirklich sinnvoll für die meisten, die keinerlei Unterschied bei ihren drei Verwendungen feststellen werden? Ausführungsgeschwindigkeit hängt von zu vielen Unbekannten ab, so dass sie nicht wirklich als generelles Argument heranzuziehen geht.

Ich würde mich auf das Nennen von feststehenden Eigenschaften beschränken und das Werten als Vor- oder Nachteil zu vermeiden versuchen. Ob etwas vorteilhaft oder nachteilig ist, kommt vor allem auf den konkreten Anwendungsfall an. Da lassen sich doch bestimmt schon genug fachliche Beispiele finden, anhand derer man die von den Entwicklern der Sprache definierten und feststehenden Eigenschaften vergleichen kann.

dedlfix.

[Gunnar Bittersmann]

@@Rolf b

ich mag mich nicht wiederholen, darum verlinke ich mich einfach selbst:

Ich mag mich auch nicht wiederholen, darum verlinke ich mich auch einfach selbst.

LLAP 🖖

[MaikS]

Moin,

vielleicht hilft dir das ja irgendwie, auch wenn es dort ums Scrollen geht:

Mobile browsers try to save battery wherever they can. That's why mobile browsers delay the execution of JavaScript while you are scrolling.

The Problem with mobile...

hth MaikS

[Rolf b]

Danke für den Hinweis. Aber ich habe es auf einem Desktop ausprobiert. Auf mehreren, um genau zu sein. Dass die Dose dann in einen Stromsparmodus geht, fände ich merkwürdig. Vor allem, wenn ich nach dem Page Refresh ein paar Sekunden warte und dann im 5-Sekundentakt den Test-Button klicke. Das erste Mal ist fix, der Rest lahm. Und es ist nur in Chrome, dass er so extrem lahm wird. Nicht im IE, nicht im ASUS Browser. Im Firefox ist der erste Klick schnell, die Folgeklicks werden dann immer langsamer (gelegentlich sind ein paar schnelle dabei). Offenbar hat der Wahnsinn also irgendeine Methode; ich weiß nur nicht, welche JS Besonderheit mir hier ein Bein stellt. Ich allociere keinen Speicher in den Durchläufen (außer Stackspace), also sollte es der GC nicht sein.

Rolf