Hallo zusammen,
um meine .lst-Dateien (erzeugt vom Total Commander mit dem DiskDirExtended-Plugin) in Excel-kompatible txt-Dateien zu konvertieren, habe ich die angehängte Batch-Datei geschrieben. Es werden dabei nur Bordmittel von Windows verwendet und läuft auf Vista sowie XP.
Nun denn, dachte ich, nachdem der Code getestet war: mach mal...
Tja, das Resultat war ernüchternd, als ich auf die Anzeige mit freiem Speicher in der Sidebar schaute. Da hatte das Skript gerade mal 60 kleinere Dateien abgearbeitet. Der Speicher von 3 GB war nahezu voll (siehe angehängtes Bild). Und mit jeder Sekunde waren weitere 1-3 MB Speicher belegt. Offen war nur noch die CMD-Sitzung, in der das Skript gestartet worden war.
Alle Analysen (Prozess Explorer, TaskManager) besagten, dass die "findstr"-Prozesse immer wieder sauber beendet wurden... soso
Habe dann noch den Screenshot gemacht, gewartet, ... und irgendwann war der Speicher voll. So voll, dass die Anzeige im Gadget für die drei Werte (freier Speicher, vorhandener Speicher, belegter Speicher) nur noch --- anzeigte. Da wurde es mir dann zu bunt und ich wollte das Drama beenden. Keine Chance: jeder Programmstartversuch, so auch beim Taskmanager wurde mit der Fehlermeldung quittiert: Nicht genügend Systemressourcen verfügbar! Welcome back to Windows 3.11!
Die CMD-Sitzung ließ sich zwar noch schließen, aber es ging weiterhin nichts mehr. Herunterfahren..., ne ne, dafür muss wohl irgendwo noch ein notwendiger Prozess gestartet werden. Ging also auch nicht. Also nur noch die harte Variante.
In weiteren Sitzungen konnte ich das Phänomen jederzeit reproduzieren. Und das Beste ist: der Speicher, der ganz offensichtlich durch findstr belegt wird, wird nicht wieder freigegeben. Ergo beleibt unter Vista nur die Möglichkeit die Konvertierung etappenweise zu erledigen.
Test auf meinem alten Notebook (Toshiba P4@1,6GHz, 512MB) unter XPSP2: Skript läuft, aber merkwürdigerweise nicht sehr viel langsamer, und belegt nicht mehr als max. 8 MB Speicher, die sofort nach jedem findstr-Durchlauf wieder freigegeben werden.
Im Zusammenhang mit diesen Erkenntnissen habe ich mal spaßeshalber "mem" unter Vista eingegeben:
655360 bytes total conventional memory
655360 bytes available to MS-DOS
592832 largest executable program size
1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area
AUTSCH!
Ok, gleiche Ausgabe unter XP, aber auf den ersten Blick fühlt man sich da doch glatt veräppelt
.
So long,
Knarf
PS: convlstf konvertiert eine einzelne .lst-Datei, convlst alle .lst-Dateien im aktuellen Verzeichnis und allen Unterverzeichnissen, wobei auf convlst2 zurückgegriffen wird. Keine Garantie auf diese Weichware, die nun wirklich keine Ausgeburt perfekter Laufzeitoptimierungen darstellt.
um meine .lst-Dateien (erzeugt vom Total Commander mit dem DiskDirExtended-Plugin) in Excel-kompatible txt-Dateien zu konvertieren, habe ich die angehängte Batch-Datei geschrieben. Es werden dabei nur Bordmittel von Windows verwendet und läuft auf Vista sowie XP.
Nun denn, dachte ich, nachdem der Code getestet war: mach mal...
Tja, das Resultat war ernüchternd, als ich auf die Anzeige mit freiem Speicher in der Sidebar schaute. Da hatte das Skript gerade mal 60 kleinere Dateien abgearbeitet. Der Speicher von 3 GB war nahezu voll (siehe angehängtes Bild). Und mit jeder Sekunde waren weitere 1-3 MB Speicher belegt. Offen war nur noch die CMD-Sitzung, in der das Skript gestartet worden war.
Alle Analysen (Prozess Explorer, TaskManager) besagten, dass die "findstr"-Prozesse immer wieder sauber beendet wurden... soso
Habe dann noch den Screenshot gemacht, gewartet, ... und irgendwann war der Speicher voll. So voll, dass die Anzeige im Gadget für die drei Werte (freier Speicher, vorhandener Speicher, belegter Speicher) nur noch --- anzeigte. Da wurde es mir dann zu bunt und ich wollte das Drama beenden. Keine Chance: jeder Programmstartversuch, so auch beim Taskmanager wurde mit der Fehlermeldung quittiert: Nicht genügend Systemressourcen verfügbar! Welcome back to Windows 3.11!
Die CMD-Sitzung ließ sich zwar noch schließen, aber es ging weiterhin nichts mehr. Herunterfahren..., ne ne, dafür muss wohl irgendwo noch ein notwendiger Prozess gestartet werden. Ging also auch nicht. Also nur noch die harte Variante.
In weiteren Sitzungen konnte ich das Phänomen jederzeit reproduzieren. Und das Beste ist: der Speicher, der ganz offensichtlich durch findstr belegt wird, wird nicht wieder freigegeben. Ergo beleibt unter Vista nur die Möglichkeit die Konvertierung etappenweise zu erledigen.
Test auf meinem alten Notebook (Toshiba P4@1,6GHz, 512MB) unter XPSP2: Skript läuft, aber merkwürdigerweise nicht sehr viel langsamer, und belegt nicht mehr als max. 8 MB Speicher, die sofort nach jedem findstr-Durchlauf wieder freigegeben werden.
Im Zusammenhang mit diesen Erkenntnissen habe ich mal spaßeshalber "mem" unter Vista eingegeben:
655360 bytes total conventional memory
655360 bytes available to MS-DOS
592832 largest executable program size
1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area
AUTSCH!
Ok, gleiche Ausgabe unter XP, aber auf den ersten Blick fühlt man sich da doch glatt veräppelt
.So long,
Knarf
PS: convlstf konvertiert eine einzelne .lst-Datei, convlst alle .lst-Dateien im aktuellen Verzeichnis und allen Unterverzeichnissen, wobei auf convlst2 zurückgegriffen wird. Keine Garantie auf diese Weichware, die nun wirklich keine Ausgeburt perfekter Laufzeitoptimierungen darstellt.
