Ich denke, dass dieser Screenshot einer tatsächlich vorhandenen Messung der Produktivität ausreicht, um die Bedeutung des Artikels zu vermitteln. Wenn der Leser jedoch an meinen Gedanken zu diesem Thema interessiert ist, ist er willkommen.
Programmierer sind von der Geschwindigkeit der Programmausführung besessen. Wir überwachen die Geschwindigkeit auch dann, wenn diese Geschwindigkeit nicht sehr wichtig ist. Manchmal entgegen dem gesunden Menschenverstand und der Logik. Nicht einmal vollständig verstehen, was die Wörter "Geschwindigkeit" oder "Leistung" in jedem Fall wirklich bedeuten. Wir wollen immer noch die schnellste Hardware, die schnellste Sprache und das leichteste Framework.
Gerne glaube ich, dass Sie, Benutzername, nicht so sind. Dass Sie selbst in der Lage sind, den richtigen Benchmark zu schreiben, wissen, wie diese oder jene Laufzeit funktioniert, dass Sie die Geschwindigkeitsoptimierung nur aus Gründen der Geschwindigkeitsoptimierung hassen und viel über Hardware wissen. Aber es gibt mehr Leute aus dem vorherigen Absatz. Überprüft.
Als ich das Beispiel auf dem Bild oben sah, verschluckte ich mich zuerst an Kaffee ...
- Wie kann Typoskript schneller als Javascript arbeiten und gleichzeitig ein Vielfaches weniger Speicherplatz verbrauchen ?!
- Auf keinen Fall!
Typoskript hat keine eigene Laufzeit. Das heißt, Sie können Typoskript nirgendwo oder fast überall ausführen. Sie müssen es zuerst in Javascript kompilieren, das dann zur Laufzeit ausgeführt wird, was genau dieses Javascript versteht. In diesem Fall fungierte der Knoten v11.3434 als solche Laufzeit. Glücklicherweise läuft das Javascript-Beispiel auch zur gleichen Laufzeit.
Anstatt Sprachen zu vergleichen, bekommen wir einen Mikrowettbewerb in der Sportprogrammierung.
→ Typoskriptcode
→ Javascript-Code
Es stellt sich heraus, dass Laufzeit, Speicherverbrauch und andere Merkmale entscheidend davon abhängen, wer diesen Bestätigungscode wie geschrieben hat. Natürlich können Sie hier das Argument abfangen, dass Typoskript Sie zwingt , "den richtigen Code" zu schreiben. Aber niemand stört sich daran, Typoskript in Javascript zu kompilieren, und ich habe auch keine Orte mit Optimierungen gesehen.
Übrigens, wie lange haben Sie schon jemanden gesehen, der einen ähnlichen Code geschrieben hat, und er wurde überprüft? Fest, OOP und FP riechen hier nicht. Der Code ist explizit prozedural geschrieben. Weil er eine andere Aufgabe hat. Richtig verstehen, obwohl der Code das Problem löst, muss er vor der Produktion überarbeitet werden. Und es ist nicht bekannt, wie sich Refactoring auf die Leistung auswirkt. Aber das ist wahrscheinlich ein Trottel.
Wir haben ein Beispiel gefunden. Offensichtlich ist das Beispiel unzureichend.
Aber mal sehen, wie andere Programmiersprachen den gleichen Test bestanden haben.
Was denkst du, wie richtig ist es zu schließen, dass Swift schneller ist als Go? Ich denke das ist falsch. Es genügt zu sehen, dass sich zwei Rust-Implementierungen (Zeilen 2 und 6) zeitlich zweimal unterscheiden.
Und hier sieht das Problem schon ernster aus. Wenn das Vergleichen von Typoskript und Javascript als Witz angesehen wird, ist das Problem bei anderen Sprachen nicht so offensichtlich. Und würden Sie anfangen zu verstehen, was los ist, wenn Sie einen solchen Bericht sehen?
Es stellt sich heraus, dass der Benchmark-Code genau überwacht werden muss.
Frage: Wann haben Sie das letzte Mal eine Person gesehen, die versucht, die Schreibweise des Benchmark-Codes zu überprüfen, nachdem Sie standardmäßige schöne Leistungsdiagramme gesehen haben?
Ich treffe diese sehr selten. Ich denke, dass solche Ingenieure verschwindend wenige sind.
Andererseits gibt es vor meinen Augen viele Beispiele, bei denen auf der Grundlage solcher Tests eine Schlussfolgerung über die Leistung und Leichtigkeit der Technologie gezogen wird. Übrigens wird die öffentliche Meinung gebildet.
Hier können Sie die Leistung der wichtigsten Javascript-Frameworks vergleichen.
Vertrauen Sie den Ergebnissen noch? Ich nicht.
Das ist alles. Aber es gibt gute Nachrichten. Die Fähigkeiten des Programmierers haben nach wie vor einen großen Einfluss auf die Programmleistung.
Fazit:
Microbenchmarks zeigen Ihnen nichts an, es sei denn, Sie sind professionell in der Leistung für eine bestimmte Plattform. Besser noch, Sie selbst schreiben diese Benchmarks unter Berücksichtigung genau Ihrer Anforderungen und Bedingungen und verstehen gleichzeitig, was Sie tun.
PS:
Der Beitrag ist eine Antwort auf voreilige Vergleiche und Schlussfolgerungen zur zukünftigen Produktivität. Natürlich können alle Schlussfolgerungen und Argumente aus dem Artikel ohne dieses Beispiel gegeben werden, aber mit Zahlen und Einzelheiten macht es mehr Spaß und ist klarer.