Hallo zusammen, ich habe keine spezifische Frage, sondern wollte euch nur von meinem aktuellen Projekt berichten. Ich arbeite derzeit an einem Programm, das eine Datei eines bestimmten Formats einliest und die darin enthaltenen Werte auf der Benutzeroberfläche anzeigt.
Um sicherzustellen, dass das Auslesen in meinem Programm fehlerfrei ist, habe ich bereits Dateien aus verschiedenen Quellen verwendet und getestet. (Es ist erstaunlich, wie große Unterschiede auftreten können, selbst wenn der Standard derselbe ist.) Vor kurzem habe ich ein YouTube-Video heruntergeladen und festgestellt, dass mein Programm über 70 Sekunden benötigte, um die Datei zu analysieren. Das war ungewöhnlich, da ähnlich große Dateien normalerweise in ein paar Dutzend Millisekunden verarbeitet wurden.
Nach einer analytischen Untersuchung stellte sich heraus, dass die Funktion "Get_udta" besonders viel Zeit in Anspruch nimmt. Die "udta-Box", was für "user-Data" steht, enthält im Klartext Informationen wie den Autor, das Fertigungsprogramm, den Encoder-Namen und ähnliches. Dabei werden auch 639 MB Arbeitsspeicher verbraucht, obwohl die Datei selbst nur 55 MB groß ist.
Die Ursache für diese Anomalie fand ich schließlich in der Tatsache, dass die "udta-Box" leider 820441 Bytes enthält. Diese Bytes beinhalten die gesamte Videobeschreibung des YouTube-Videos sowie (salopp gesagt) einen Großteil der Weltgeschichte. Das Programm musste über 70 Sekunden lang zusammenhängenden Speicher suchen, insbesondere weil der String zusätzlich mit
Daher meine Bitte an euch: Seid vorsichtig mit großen Strings und programmiert eine Sicherheit ein:
Verschoben. ~Thunderbolt
Um sicherzustellen, dass das Auslesen in meinem Programm fehlerfrei ist, habe ich bereits Dateien aus verschiedenen Quellen verwendet und getestet. (Es ist erstaunlich, wie große Unterschiede auftreten können, selbst wenn der Standard derselbe ist.) Vor kurzem habe ich ein YouTube-Video heruntergeladen und festgestellt, dass mein Programm über 70 Sekunden benötigte, um die Datei zu analysieren. Das war ungewöhnlich, da ähnlich große Dateien normalerweise in ein paar Dutzend Millisekunden verarbeitet wurden.
Nach einer analytischen Untersuchung stellte sich heraus, dass die Funktion "Get_udta" besonders viel Zeit in Anspruch nimmt. Die "udta-Box", was für "user-Data" steht, enthält im Klartext Informationen wie den Autor, das Fertigungsprogramm, den Encoder-Namen und ähnliches. Dabei werden auch 639 MB Arbeitsspeicher verbraucht, obwohl die Datei selbst nur 55 MB groß ist.
Die Ursache für diese Anomalie fand ich schließlich in der Tatsache, dass die "udta-Box" leider 820441 Bytes enthält. Diese Bytes beinhalten die gesamte Videobeschreibung des YouTube-Videos sowie (salopp gesagt) einen Großteil der Weltgeschichte. Das Programm musste über 70 Sekunden lang zusammenhängenden Speicher suchen, insbesondere weil der String zusätzlich mit
.TrimStart(TrimChars)
bearbeitet wird.Daher meine Bitte an euch: Seid vorsichtig mit großen Strings und programmiert eine Sicherheit ein:
Verschoben. ~Thunderbolt
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Thunderbolt“ ()