Daaron schrieb:
Immerhin hab ich gestern tatsächlich eine JS-Animation gefunden, die einen i5-2400 (unter Ubuntu x64 mit aktuellem Chromium Build) auf allen Kernen auf 40% Last hält: ein kleines Background-Script, dass 40 "Fussel" auf recht zufälligen Bahnen durchs Bild schweben lässt.
das lag dann aber nicht daran, dass JavaScript zu langsam ist, sondern dass da wieder ein "Entwicklergenie" entwickelt hat. Und eventuell am Browser-Rendering, wenn man das nicht geschickt macht kann das echt kosten, also wenn die 40 Fussel einzelne Browser-Renderings sind und nicht batched gemacht werden.
Dese schrieb:
du sagtest 99% der anwendungen sind nicht zeitkritisch. zeitkritisch ist ein so weitreichender und schwamminger begriff, dass schon allein deswegen jede zahl an grundlage entbehrt.
ok, mit den Zahlen war doof, sehe ich ein. Dann verbessere ich mich: Solange kein Entwicklervollpfosten entwickelt, wird quasi keine JavaScript-Anwendung an die Performance-Grenzen von JavaScript stoßen, also keine Realworld-Anwendung.
Wer natürlich AES in JavaScript entwickelt und damit eine 1GB Datei verschlüsseln will....
Dese schrieb:
performance zu verbessern sollte ausserdem nicht allein aus "zeitkritischen" gründen motiviert sein.
wenn du die 5% performance verbesserung offenbar nur wegen "nicht zeitkritisch" ignorieren willst, dann klingt das sehr danach.
Ich sage nicht, dass man nicht an der Performance arbeiten soll, dann hast du mich gründlich falsch verstanden. Aber einfach eine neue Sprache zu designen mit der Behauptung als Ziel, dass es dann schneller als JavaScript ist, ist einfach nur sinnlos. Jede Sprache ist nur so gut wie ihr Compiler.
Googles V8 Engine ist sogar im Language Shoout Game (wirklich kein absoluter Vergleich, aber ein netter Anhaltspunkt) schneller als Googles strikt typisierte Sprache Go. Es hängt vom Compiler ab und da kann bei JavaScript immernoch mehr als genug tun und das macht Google auch.
Dese schrieb:
der rest deines posts hat nichts mit meinem zu tun. ich glaube du hast dich da in einer erwartungshaltung hineingesteigert und was in meinem post gesehen, was da weder drinn steht noch gemeint war. denk mal drüber nach.
dann entschuldige ich mich, aber deine Aussage klingt absolut provokativ in die Richtung, dass man doch bitte Dart nehmen soll weil JavaScript langsam wie die Hölle ist und wir etwas effizienteres brauchen.
Dese schrieb:
welche die aber einen für das gebotene lächerlich hohe cpu-auslastung verursacht begegnet mir fast täglich. js ist durch die verbesserungen der vms ENORM verbessert worden, von performant ist man aber noch weit entfernt.
nur weil ein dämlicher Entwickler irgendwelchen Mist macht, ist doch noch nicht JavaScript infperformant. Ich kann dir auch Assembler-Code schreiben, der dir deinen Rechner voll auslastet.
Dese schrieb:
es gibt einfach zu vieles was auf den ersten blick als richtig aussieht aber brutalen performance-impact hat. das ist allerdings weniger ein problem der sprache ansich (syntax und semantik), als vielmehr des modells auf das es wirkt (die vm macht davon nur einen teils aus).
Da muss ich eben wehement widersprechen
Ich entwicklere unter anderem in Node.js also auch Software auf Basis von JavaScript mit Sockets und allem drum und dran. Und ich kann dir sagen, dass bei Node.js auf lange Zeiten JavaScript nicht limitiert. Auf einem einzigen Core (da singlethreaded) bekomme ich 3500 HTTP Request/Sekunde, also langsam kann das nicht sein und das sind keine Hello World Ausgaben.
Und im Browser wird noch weit weniger JavaScript ausgeführt, als in so einer Node.js-Anwendung. Wenn es da soviel Leistung frisst, ist es fast immer das Browser-Rendering. Da werden dann in einer Schleife 50 Elemente des DOM modifiziert, statt alles in einer Operation zu machen und den ganzen betreffenden DOM-Baum auszutauschen. Es sind also im Endeffekt 50 Zeichenoperationen für den Browser, DAS killt die Leistung und DAS verursacht die hohe CPU-Last. Die JavaScript-Operationen laufen immer nur einen Bruchteil einer Millisekund, mal abgesehen von genialen Konstrukten wie diesem (da sind aber die Entwickler Schuld):
Code:
function sleep(ms) {
var start = new Date().getTime();
while(start + ms > new Date().getTime());
}
Wie gesagt: JavaScript hat wie Java aus den Urzeiten immernoch diesen "Bad Taste" es sei langsam wie sonstetwas. Aber die Technik hat sich entwickelt und es ist mitlerweile schnell genug für fast alles, eben bis auf Spezialfälle. Und wenn dann wiedermal eine Webseite Leistung frisst dann ist JavaScript Schuld, aber das muss es gar nicht sein wie ich schon sagte, das Browser-Rendering ist viel wahrscheinlicher oder man hat eben einen Programmierergott gehabt der sich irgendwo verewigt hat.
