Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Arno Welzel Newsgroups: de.comp.lang.javascript Subject: Re: Gluecksrad Date: Fri, 18 Nov 2016 17:23:47 +0100 Lines: 68 Message-ID: References: <3307965.kQq0lBPeGt@PointedEars.de> <1a76ea3d-6da6-d368-78b5-3073fe844d07@arnowelzel.de> <10725728.O9o76ZdvQC@PointedEars.de> <4986933.DvuYhMxLoT@PointedEars.de> <1763443.oMNUckLgyt@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net flUBCJGgknuMcve1MW/YHQR0HZpHPMXKZ/sXWwWrcSko8axJBp Cancel-Lock: sha1:S1tZs/Ai9Q+NdoMJeQ3dVOrOwtw= In-Reply-To: <1763443.oMNUckLgyt@PointedEars.de> Xref: csiph.com de.comp.lang.javascript:4805 Thomas 'PointedEars' Lahn schrieb: > Arno Welzel wrote: > >> […] Performanceprobleme erkenne in der *Praxis* ich keine, >> selbst wenn die Performanceunterschiede verschiedener Umsetzungen >> theoretisch messbar sein mögen. > > Je länger man Deine Website anschaut, umso mehr Arbeitsspeicher frisst sie, > weil immer mehr davon für immer neue Objekte reserviert werden muss – > unnötiger Weise. Irgendwann wird dann der Tab oder der Browser vom OOM- > Killer abgeschossen oder das System hängt. Das ist nicht nur theoretisch > messbar (was BTW ein Widerspruch in sich ist; Messungen sind immer Praxis). Aha - und welcher Umgebung soll das sein? Hier mit Linux Mint 14 und Firefox 49 lässt sich das nicht reproduzieren. Auch nach mehrere Stunden ist der Speicherbedarf nicht angestiegen, der OOM-Killer wird logischerweise auch nicht aktiv und ein hängendendes System habe ich ebenfalls nicht. Eine kurzer Vergleich mit Windows 7 und Firefox 49 sowie IE 11 wie auch Firefox unter MacOS hat ebenfalls keine Auffälligkeiten gezeigt. > Über den Rest Deiner DAU-dummen Reaktion breiten wir lieber den Mantel des > Schweigens. Zeige mir, was an der verwendeten switch()-Anweisung konkret *falsch* ist oder lass' es. Und nein, damit meine ich nicht, dass man es auch anders machen *kann*, sondern wieso man es anders machen *müsste*: switch(req.readyState) { case 4: break; default: break; } Und zum Thema "Sicherheit": zeige mir, welches ausnutzbare(!") Sicherheitsproblem bei meiner Verwendung von windows.setTimeout() übergibt. Und ja, die Problematik von eval() ist mir sehr wohl bewusst und ja, wenn ich es mal umbaue, werde ich sicher eine andere Lösung bevorzugen. Mir aber vorzuhalten, der vorhandene Code hätte ein Sicherheitsproblem, dann aber auf allgemeine Erläuterungen dazu zu verweisen, ohne das konkrete(!) Problem zu zeigen, ist sinnfrei. Und zum Thema "theoretische Messung ist Widerspruch": Damit meine ich, dass man etwas zwar mit Messungen zeigen kann, dass die Theorie einer schlechteren Performance stimmt, die gemessenen Ergebnisse für die Praxis aber nicht relevant sind. Zu guter letzt: Der TeamSpeak-Server wird mit einer Lizenz für 512 User betrieben und entsprechend rege genutzt und ebenso nutzen sehr viele Leute das gezeigte Script entweder direkt bei mir auf der Website oder eingebunden auf einer anderen Site - und das schon seit etlichen Jahren. Du kannst Dir sicher sein, dass ich es mitbekommen hätte, wenn es dort ein Problem mit stetig wachsendem Speicherverbrauch oder gar hängenden Systemen gegeben hätte. -- Arno Welzel https://arnowelzel.de https://de-rec-fahrrad.de http://fahrradzukunft.de