Fortschritt. Oder nicht? //2289

Auch kurz vor dem Jahresende gibt es noch einiges in der Firma zu tun.
Ich hatte einem meiner Mitarbeiter aufgetragen, eine Funktion zu schreiben, die aus einer gegebenen Liste von ein paar Tausend Dateien den jeweiligen MD5-Hash (ja, ich weiß, dass der MD5 nicht mehr als sicher gilt, es geht hier aber überhaupt nicht um einen sicherheitskritischen Zweck, sondern darum, die Dateiinhalte eindeutig unterscheiden zu können) ermittelt.
Die Funktion des Mitarbeiters lieferte korrekte Ergebnisse, aber die Performance war mies. Man musste fast minutenlang warten. Also schauten wir, ob wir nicht einen schnelleren Algorithmus finden würden. Er hatte die Grundlage für den Code für die Hashberechnung im Internet gefunden und angepasst. Ich erinnerte mich, dass ich für entsprechende Berechnungen immer eine API-Funktion des Betriebssystems genutzt hatte. Ob die allerdings merklich schneller laufen würde, wusste ich auch nicht.
Gemeinsam mit dem Mitarbeiter stellten wir den Code um. Und tatsächlich – in unserem Testsystem lief die Funktion deutlich schneller. Das heißt natürlich nicht, dass sie das immer tut. Wenige große Dateien können sich anders verhalten als viele kleine, auch wenn die Gesamtdatenmenge übereinstimmt.
Ich trug dem Mitarbeiter auf, noch ein wenig mit anderen Szenarien zu testen, aber vermutlich wird es bei der API-Funktion bleiben.

Perspektivenwechsel: Bestimmt hat jeder von euch sich schon einmal geärgert, oder zumindest gewundert, wenn eine Fortschrittsanzeige (z.B. bei einer Installation) so überhaupt nicht zu passen scheint. Da hängt der Balken minutenlang, dann wieder macht er einen Sprung, die prognostiziert verbleibende Zeit wird immer länger statt kürzer, um irgendwann, wenn man es schon fast aufgegeben hat, ganz plötzlich fertig zu sein. Warum ist das so? Warum läuft der Fortschrittsbalken nicht einfach gleichmäßig und stetig durch, und die verbleibende Zeit nimmt linear ab?
Man muss sich mal überlegen, wie man selbst solche Fortschritte berechnen würde. Bei komplexen Aufgaben wie einer Installation kommen viele Einzeltasks zusammen (z.B. Registryeinträge), die alle unterschiedlich lange dauern können, und das abhängig vom jeweiligen System. In unserem Beispiel beschränken wir uns deshalb auf den Use Case, dass mehrere Gigabyte Daten, aufgeteilt in tausende Dateien innerhalb hunderter verschachtelter Verzeichnisse umkopiert werden sollen.
Wenn dafür das Source-Verzeichnis angegeben wurde, weiß man zunächst nicht, wie viele Dateien überhaupt enthalten sind, und wie groß sie sind. Natürlich könnte man in einem ersten Schritt, die Verzeichnisstruktur rekursiv durchlaufen, um zunächst die Dateien zu zählen und ihre Größen aufzusummieren. Das dauert aber natürlich auch, und bringt eigentlich nichts, außer etwas zuverlässigere Informationen für den Nutzer. Möglich wäre sogar, dass sich die Dateien zwischenzeitlich ändern. Je nach intended use kann man das also vorher machen, oder doch lieber nicht.
(Die Möglichkeit, die einzelnen Aufgaben in mehrere unabhängige Threads aufzuteilen, ignorieren wir hier mal.)

In erster Näherung kann man dann den Ansatz für die insgesamt benötigte Zeit t_ges machen: t_ges = t_0 + t_N*N + t_S*S, t_0 ein Offset, der grundsätzlich benötigt wird, t_N die Zeit pro Datei, t_S die Zeit pro Informationseinheit, N die Anzahl der Dateien, und S die Gesamtinformationsmenge der zu bearbeitenden Dateien.
Wer es noch genauer braucht, kann in einem weiteren Summanden t_D*D auch noch die Anzahl der Verzeichnisse D berücksichtigen. Das dürfte aber in den meisten Fällen nicht viel bringen, und den Aufwand noch weiter erhöhen. Höhere Potenzen noch hinzuzunehmen, dürfte erst recht nicht lohnen.
Nachdem das Programm die ersten Dateien übertragen hat, kann es aufgrund der gemessenen Zeiten unter Benutzung des obigen Ansatzes die Parameter t_? berechnen. Bei drei Unbekannten braucht es dafür drei voneinander unabhängige Zeitpunkte.
Diese Parameter ermöglichen dann eine erste Abschätzung, die dem Nutzer angezeigt werden kann.

Gerade beim Kopieren, aber ebenso bei anderen Vorgängen, hängt die benötigte Zeit auch davon ab, was der Computer sonst noch gleichzeitig macht, und wie weitere Resourcen ausgelastet sind – etwa die Netzwerkbandbreite beim Zugriff auf einen Share. Oder auch, ob benötigte Daten bereits im Cache oder sonstwo vorhanden sind. Die Geschwindigkeit kann also variieren. Das heißt, die genannten Parameter t_? sind nicht konstant, sondern können sich verändern.
Es empfiehlt sich deshalb, die Zeitmessung nicht von Anfang an in die Berechnung einfließen zu lassen, sondern nur die letzten vielleicht fünf Minuten, oder was angesichts der konkreten Aufgabenstellung als zweckmäßig erscheint.

Ihr merkt schon – das kann beliebig kompliziert werden. Ich belasse es deshalb bei diesem kleinen Einblick, was man alles berücksichtigen müsste. Es ist hoffentlich klar geworden, warum eine Fortschrittsanzeige grundsätzlich nicht zuverlässig funktionieren kann, und man sich verlässlichen Ergebnissen nur ungefähr annähern kann.
Wenn ihr euch das nächste Mal wieder über eine merkwürdig erscheinende Fortschrittsanzeige wundert, erinnert euch hieran.