Langsamer Nachdenken
« | 11 Feb 2019 | »In der Programmierung zieht sich ein bestimmter Faden durch meine persönliche Entwicklung, die die Art der Nutzung der Sprachen entscheidend geprägt hat.
Und dabei handelt es sich um “langsamere” Systeme.
In Jugendtagen lag dies stets an fehlenden Geldmitteln, dass das Low-Cost System eingekauft wurde und die High-End Gamer-Maschine gar nicht erst beachtet wurde.
Dieses Situation hat sich bis heute nicht geändert, obwohl es heute einen
taktischen und keinen finanzieller Hintergrund dafür gibt.
Denn die Devise lautet: “guten” Code zu produzieren, der auch auf
langsameren und älteren Systemen vernünftig ausführbar sein soll.
Wer mit BASIC-Dialekten beginnt, darf keine Geschwindigkeitsrekorde auf Computern erwarten. Selbst das seit Version 5 mit nativen Code optimierte Visual Basic generierte interne Strukturen die ein Vielfaches der eigentlich nötigen CPU Instruktionen erzeugte … und genau so schwerfällig langsam war dann die Ausführung.
Schon zu Windows 3.1 Zeiten wollte ich “coole” Abdunkelungs-Effekte erarbeiten, die aber sekundenlange CPU-Spitzen produzierten und manchmal sogar in Abbrüche aus Speicherknappheit führten.
Seither verzichte ich gerne auf solche “billigen” nur scheinbar “coolen” Effekte und habe mehr Spaß daran, wenn ein Klick sofort zu einem Ergebnis führt und nicht erst lange an Warte-Animationen herumlädt.
Bei einem Bekannten war dies alles anders, weil er jeden freien Cent in die Aufrüstung seiner PCs steckte und wenn man eben die doppelte Rechenkapazität hat, sind die Wartezeiten eben nur halb so lang und folglich erträglicher.
Ich denke, dass die Industrie hier einen negativen Effekt auf die Softwareentwicklung einbringt. Denn mit dem Argument
Kaufen Sie sich einfach einen neuen PC!
geht uns nach und nach das Erarbeiten von optimierten Programmen verloren.
Denn mal ehrlich: Nachdem eine “coole” Animation 2 bis 3 mal angesehen wurde,
ist sie einem herzlich egal.
Dass aber das Laden und Anzeigen einer solchen den eigentlichen Rechenprozess
jedes mal in die Länge ziehen kann, nervt auf Dauer sehr.
Es kostet mehr Strom, produziert somit mehr CO2 und senkt die Produktivität des Anwenders.
Mein Aufruf lautet daher:
Liebe Entwickler! Arbeitet mal auf der vergangenen CPU-Generation.
Und wenn eure Programme dort schlecht ausgeführt werden, überdenkt euren Code!
Denn unterschiedliche Tests haben mich zur Erkenntnis gebracht,
dass der Großteil an Rechenverlust auf
UI-Seite stattfindet.
System-APIs reagieren auf den meisten Plattformen durchaus zügig. Doch deren
Anzeige auf dem Schirm schneidet dramatisch ab.
Mein deutlichstes Negativ-Beispiel ist Microsofts dotNet Framework in der Server-Verwaltung. Denn während mir die WMI-APIs die System-Logs von tausenden Einträgen binnen einer Sekunde vollständig liefen können, ist das Starten der Management-Console und der dortige Klick zur “Ereignisanzeige” eine Angelegenheit von 10 Sekunden und mehr.
Was zur Hölle passiert denn da, dass wir eine Wartezeiterhöhung von 1000 % hinnehmen müssen?
Es werden hunderte DLLs geladen und anschließend wieder entladen, die Anzeige
stockt und braucht ewig, bis die ersten Einträge angezeigt werden.
Und am Ende sehen wir trotzdem nur eine
ListView
mit ein paar Icons.
Wer sich jedoch noch an den Server 2003 erinnert, als Programme noch nativ mit C++ erstellt wurden, der weiß, dass die gleiche Anzeige auch in 2 Sekunden auf dem Schirm sein kann.
Deshalb liebe ich C++, auch wenn es manchmal komplizierter erscheint. Doch sein
Aufbau bringt uns dazu an Software zu denken und nicht an billige Effekte.
Und statt Code zu interpretieren, der nur auf dem neuesten Prozessor
einigermaßen “rennt” und nicht träge dahinschleicht, erhalten wir schlanke
(um nicht zu sagen sportliche) Komponenten, die zügig agieren und reagieren.