Der Zeckengraf //2515

Unter all meinen selbstgeschriebenen Tools ist auch eines, das mich beim Verwalten meiner Daten unterstützt. Für einen Durchlauf braucht es mehrere Minuten, aber da dies im Hintergrund geschieht, stört mich das nicht. Ich sehe keine Veranlassung, die Performance weiter zu optimieren.
Es war mir allerdings aufgefallen, dass dieses Tool offenbar wesentlich länger läuft, wenn ich es von meinem Server aus starte, als direkt auf meiner Entwicklermaschine. Dafür kann es viele Gründe geben. Bevor ich dem eventuell nachgehen würde, wollte ich aber erst einmal herausfinden, ob mein subjektiver Eindruck nicht trog, und tatsächlich ein signifikanter Unterschied bestand.
Natürlich hätte ich einfach beim Starten auf die Uhr schauen können. Aber da ich es meistens gar nicht sofort mitkriege, wenn das Programm fertig ist, hätte das nichts gebracht.
Aber selbstverständlich kann sich das Tool selbst merken, wenn es losläuft, und am Ende dann ausgeben, wie viel Zeit seither vergangen ist. Das sind drei oder vier Zeilen Code.

Gedacht, getan.
Ich deklarierte eine int-Variable für die Startzeit, und speicherte ganz am Anfang den Tickcount (das ist die Anzahl der Millisekunden, seit der Computer zuletzt gestartet wurde) des Rechners in diese ab.
Nach dem Bearbeiten der Daten berechnete ich dann die Differenz aus dem dann aktuellen Tickcount und der Startzeit, teilte sie durch 1000, und gab sie aus.
Auf der Entwicklermaschine funktionierte das auf Anhieb. Ein erster Probedurchlauf lieferte knapp fünf Minuten, was plausibel war.
[Überraschenderweise ist die VM reproduzierbar sogar deutlich schneller als ihr Host. Über Gründe möchte ich nicht spekulieren, und erwähne diese seltsame Beobachtung hier auch nur am Rande. Vielleicht eine WoW64-Sache?]

Jetzt brauchte ich noch den Vergleich zum Server. Es war mir bewusst, dass die Daten bereits bearbeitet waren, so dass dies die Messung verfälschen würde, da der Server weniger zu tun haben würde, ging aber davon aus, dass dieser Unterschied minimal sein würde, höchstens ein oder zwei Sekunden, auf die es nicht ankommt.
Also ließ ich den Server einige Zeit vor sich hin rödeln.
Schließlich hatte er das Ergebnis und spuckte es aus. Ich las irgendwas mit 4.2 Millionen. In diesem Augenblick war mir erst mal nicht bewusst, dass ich ja die Sekunden ausgab. Ich ging von Millisekunden aus. Das wären dann über 70 Minuten gewesen. So lange hatte er aber denn doch nicht gebraucht. Das konnte nicht stimmen. Inzwischen war mir auch wieder eingefallen, dass ich ja auf Sekunden umgerechnet hatte. Dann war das Ergebnis erst recht Unsinn.
Mir ist ja klar, dass GetTickCount() bei gut 7 Wochen Laufzeit überläuft, aber mein Server lief zu dieser Zeit erst seit etwa fünf Wochen. Ich hielt das für kein Problem, denn selbst wenn der Zähler irgendwann übergelaufen ist, ist das irrelevant, weil ich ja nur die Differenz auswerte. Für den unwahrscheinlichen Fall, dass das Programm gerade dann läuft, wenn der Zähler überläuft (also vorher startet, danach fertig ist), hätte ich das als seltene und bemerkenswerte Kuriosität gewertet. Solange das Programm nur für meinen Eigenbedarf ist, also nicht an Kunden geht, gönne ich mir solch außergewöhnliches Verhalten. [Und ohne jetzt näher darauf eingehen zu wollen: ja, ich weiß, dass es auch GetTickCount64() gibt, aber ich hatte gewichtige Gründe, es nicht zu benutzen.]

Zum Test schrieb ich dann ein kleines Konsolenprogramm (also völlig ohne graphische Oberfläche), das einfach mehrmals die Anzahl der Ticks ausgeben sollte.
Nachdem das einwandfrei funktionierte, erweiterte ich es, speicherte aber zusätzlich noch den Startwert ab, und gab ihn aus.
Als ich es dann auf dem Server laufen ließ, sah ich auch sofort das Problem. Lernt aus meinen Fehlern! Auch erfahrenen Entwicklern wie mir passiert mal so ein Lapsus.
Der in eine int Variable abgespeicherte Startwert war negativ. Dadurch dass ich die 32 bit des Tickcounts in eine vorzeichenbehaftete Variable gespeichert hatte, war das most significant bit als Vorzeichenbit gelesen worden, was natürlich falsch ist.
Nachdem ich „int“ durch „unsigned int“ ersetzt hatte, funktionierte das Progrämmchen tadellos.
Als ich später mein entkäfertes Tool auf dem Server laufen ließ, brauchte er eine gute Viertelstunde, was mit meiner Annahme übereinstimmte. Was die Gründe für die Langsamkeit betrifft, habe ich bereits Vermutungen, aber das würde jetzt zu weit führen und ist ein völlig anderes Thema. Nur ganz kurz gehe ich davon aus, dass vor allem der Netzwerkverkehr den Server ausbremst, und er hat auch einen deutlich schwächeren Prozessor. Ob das allerdings als Erklärung ausreicht, kann ich aktuell nicht sagen. Die Angelegenheit ist nicht so dringlich, dass ich ihr unbedingt sofort nachgehen müsste, wenn überhaupt. Lasse ich das Tool zukünftig eben von der VM aus laufen.

Ja, so etwas passiert, wenn man nur quick’n’dirty programmiert. Auf meiner Entwicklermaschine wäre mir dies nicht so schnell aufgefallen. Die läuft normalerweise nicht so lange. Bei Software, die ich verkaufe, lasse ich wesentlich mehr Sorgfalt walten. Software, die in Produktivsystemen eingesetzt wird, muss ausgiebig getestet werden. Aber gerade solche Langfristeffekte sind selbst in umfangreichen Systemtests kaum auffindbar. Da kann man froh sein, wenn in den Betatests, also bevor die Software offiziell freigegeben wird, etwas entdeckt wird.
[Ein Schelm, wer jetzt Assoziationen zu gewissen anderen Test- und Zulassungsverfahren hat.]

Über Anne Nühm (breakpoint)

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

5 Antworten zu Der Zeckengraf //2515

  1. Sempersolus schreibt:

    Verleser des Tages: „entkräftetes Tool“ statt „entkäfertes Tool“
    oder
    „Das Problem sitzt VOR dem Computer“

    Hannover (heise). Das in Rekordzeit entwickelte und unlängst vorgestellte Textverarbeitungsprogramm der Firma hotneedle erweist sich nach jüngsten Presseberichten als nahezu unbrauchbar. Dabei war die Software mit großen Erwartungen und viel Vorschusslorbeeren in das Rennen gestartet. Anders als bei seinen Konkurrenten sollte das Programm deutlich intuitiver und einfacher in der Anwendung sein, so benötigt man für hotneedles Produkt z.B. keinen Extrakühler. Zuletzt hatte der anfängliche Hype um das Programm noch für einen Nachfrageschub gesorgt, die Herstellerfirma sah sich sogar Vorwürfen ausgesetzt, man produziere zu langsam und die vereinbarte Liefermenge werde mutwillig unterschritten, nur um Bill Gates oder der EU eins auszuwischen. Der höre ja ohnehin jeden der Computernutzer ab.

    Wie sich jetzt herausstellt erfüllt das Programm von hotneedle zwar seinen ursprünglichen Zweck (Texte lassen sich auf hohem Niveau verarbeiten), aber dauerhaft können Nutzer nur die Farbkombination grüne Schrift auf schwarzem Grund anwählen, weshalb einige Anwender nach längerer Bildschirmarbeit über vorübergehende Kopfschmerzen, Fieber und Übelkeit berichten.

    „Es ist einfach zum Kotzen.“, so der Nutzer Norbert Nerd in einem Gespräch mit unserer Redaktion. „Das hätte man doch in der Testphase oder spätestens bei der Programmzulassung merken müssen. Ich will mein Geld zurück.“. Nach diversen gleichartigen Berichten in den Massenmedien fiel der Wert der hotneedle-Aktie an den Weltbörsen gestern ins Bodenlose. Viele Anwender wollen die neue Software nicht mehr, das Produkt liegt in den Regalen, wie Sauerbier.

    Ein großer Teil der Nutzer überlegt sich jetzt sogar, in Zukunft auf Textverarbeitungen ganz zu verzichten, so auch Nerd: „Meine Oma ist auch ganz ohne Computer 40 Jahre alt geworden, das reicht ja wohl. Außerdem hat das Programm noch viel schwerwiegendere Bugs: Immer wenn ich Alt-Ctrl-Delete drücke stürzt der ganze Rechner ab.“

    Gefällt 1 Person

  2. Plietsche Jung schreibt:

    Bottleneck ist mein I/O. Schau die mal die Prozessorlast dazu an und wahrscheinlich ist selbst der kleinere Prozessor nicht oder nicht lange am Limit.

    10GbE Netze sind auf dem Vormarsch und in den Consumer-PCs stecken heute PCI-E NVMe-SSDs. Die schaufeln schon ziemlich viele Daten pro Zeiteinheit. In Datacentern gibt es noch ganz andere Kaliber.

    Gefällt 1 Person

    • Der Prozessor kommt bei weitem nicht an seine Grenzen.
      Der Zugriff auf diverse Datenträger bremst wohl eher, und auch dass ein Teil der Daten durch das Netzwerk geschleust werden muss. Aber dennoch ist da jederzeit noch Luft nach oben.

      Eigentlich stört es mich auch gar nicht, dass es einige Zeit dauert. Diese Zeit habe ich eingeplant, und während das Programm im Hintergrund arbeitet, kann ich etwas anderes tun.
      Ich fand dennoch die unterschiedliche Zeitdauer erstaunlich, und vor allem wollte ich diesen blöden Anfängerfehler mit dem (signed) int bloggen.

      Gefällt 1 Person

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.