[Allegro] import nun korrekt bei Dateien >2GB

[Bernhard Eversberg]

Es war geschrieben worden:

 >> Die Frage ist noch, ob es so mit jeder denkbaren Endebedingung
 >> klaglos klappen wird. Darüber wird noch nachgedacht.

 > Die Aufrufe kommen herein, um folgenden Fall abzufangen:

 > Die eingelesenen Zeichen der Datei werden nacheinander
 > mit den Zeichen von re verglichen. Wenn re aus mehr als
 > einem Zeichen besteht, kann das auch nach dem ersten
 > Zeichen scheitern, dann wird auf die Stelle "zurueckgespult",
 > wo das erste Kandidatenzeichen entdeckt worden war.

 > Das laesst sich mit einigem Aufwand auch mit einem privaten
 > kleinen Hilfsbuffer implementieren (bedeutet aber u.U. pro
 > Zeichen eine Abfrage zusaetzlich, naemlich ob da etwas vorzuziehendes
 > drin steckt. Erfahrungsgemaess lassen sich solche Sachen aber
 > mit einem groesseren Hilfsbuffer ohnehin ganz erheblich beschleunigen,
 > es wird eine groessere Datenportion eingelesen und darin nach der
 > Endezeichenkombination *gesucht*).

Die Sache mit dem "größeren Hilfsbuffer" ist ein lehrbuchmäßiger
Ansatz. Geradeausdenker wählen zielsicher dieses Vorgehen.
In diesem Fall hat es seine eigenen Probleme. Die Fälle, wo der
Vergleich "nach dem ersten Zeichen scheitert", sind nicht die ganz
kritischen, sondern wenn's nach dem zweiten scheitert usw. Das Ende
eines Buffers kann ja gerade mitten im Suchbegriff liegen...
Wir haben aber eine weniger aufwendige Lösung, einen Querdenkeransatz,
gefunden. Dabei wird nur ein sehr kleiner Buffer benötigt. Es waren
noch etliche Tests nötig, um die Lösung weiter zu verbessern.
Nun scheinen damit auch die genannten Fälle stets zu klappen, und
schneller geht's immer noch als mit 16bit. Tip dazu: Den Aufruf
  import ...
ergänzen um  >nul
das geht dann noch beträchtlich schneller, weil die Konsolausgabe
einiges an Millisekunden braucht, mehr als die Aktion selbst.
Für eine Datei >2GB im Test brauchte import mit 55 Sek. rund  7% der
Zeit, die import16 brauchte (gleichfalls mit >nul gestartet). (Unter 
Win'7/32). Das war aber ein simpler Import mit nur 2 Feldern.
Bei komplexen, kompletten Importen, z.B. aus Pica-Daten nach A.CFG,
kann's auf 15% raufgehen, wie wir zugeben müssen. Die Ergebnisse
waren immerhin und immer noch bis aufs Bit genau gleich.

import.zip  liegt bereit.

B.E.