[Allegro] acon-Beobachtungen

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

I.
bei einem komplexen Export, der sich mit SRCH anstandslos produzieren liess,
crashte acon (30.8.2010) mit Dr. Watson Nachf. Stundenlanges Eingrenzen
zeigte dann die "uebliche" Ursache: Eine Schleifenkonstruktion, die eigentlich
eine Variable aufessen sollte, bis die vollstaendige Leerung dann das
Abbruchkriterium gewesen waere, verlaengerte die entsprechende Variable...
SRCH.EXE scheint sich daran unauffaelliger verschluckt zu haben. Bleibt die
Frage, wo acon nun auf den meisten Rechnern einige GB mehr Arbeitsspeicher als
SRCH.EXE zur Verfuegung hat, ob man statt des Crashs nicht eine halbwegs
aussagekraeftige Fehlermeldung spendieren koennte (etwa
"Hintergrundspeicherueberlauf" oder etwas noch konkreteres).


II.
var "xy"
xport param
if no jump ...

brachte bei nichtvorhandener xy.apr leider nicht den lt. xexport.rtf
vorgesehenen Sprung, sondern den beliebten "Exception error (Memory access)".


III.
Die zu exportierenden Datensaetze enthielten Kategorien, die mit einem oder
mehreren "|" endeten (MAB-Fuellzeichen), Vergleich der Ergebnisse von acon und
SRCH zeigte, dass in der acon-Variante ein "|" fehlte (und wenn es das einzige
Inhaltszeichen war, fehlte die gesamte Kategorie). Ich habe den Verdacht, dass
das Zeichen bei der Konstruktion
fetch rec
...
insert
in srch.job auf der Strecke bleibt, ist das plausibel oder soll ich genauere
Tests veranstalten?


IV.
Der Export konvertierte die Zeichen nach UTF-8, beim Start der Verarbeitung
eines jeden Satzes sowie unmittelbar nach jeder erfolgreichen Nachladung wird
#da
gegeben (#dA aber nur beim Verarbeitungsende, nicht vor oder nach dem
Rueckstapeln nachgeladener Saetze: ich hatte das so verstanden, dass #da auf
den aktuell obersten Satz im Nachladestapel wirkt, ist dies gleichzeitig der
unterste, wirkt es auch auf den Hintergrundspeicher. Mit welcher "Magie" ueber
|i8 und |i9 besetzte #uxi korrigiert werden, weiss ich leider nicht).

In der SRCH-Variante waren allerdings in einigen Faellen Akzente um
zwei Positionen verschoben (bzw. hinten aus dem Text "herausgefallen").
Moegliche Probleme der Parameterdatei einmal beiseite gelassen (ich habe noch
nicht systematisch untersucht, ob es in beiden Varianten uebereinstimmende
inkorrekte Doppelverschiebungen gibt): In welcher Situation ist es denn
moeglich, dass acon und SRCH.EXE Akzentvertauschung abweichend handhaben?
Hat evtl. acon einen eingebauten "Schutz", so dass der Versuch einer erneuten
Akzentvertauschung folgenlos bleibt, wohingegen SRCH diese ausfuehrt?


V.
Durchfuehrung diverser Exporte (viele Nachladungen, jedoch keine V14-
Expansionen, falls Suchbegriffe auf der Kommandozeile, dann auch -F
angegeben) an einer kleinen Datenbank (etwa 150.000 Saetze, das gesamte
Datenverzeichnis hat etwa 130MB) benoetigte mit SRCH.EXE im "Windows XP Mode"
(virtueller PC mit Windows XP) etwa 34 Minuten bei konstant 25% CPU-Auslastung
(einer von vier Kernen, mehr nutzt der "Windows XP Mode" nicht).

Dasselbe mit acon (und "meinem" srch.job) benoetigte ca. 20 Minuten (ebenfalls
Vollauslastung mit 25% CPU-Last), d.h. die Beschleunigung durch das 32bit-
Programm betraegt etwa den Faktor 1,7. Ist es denn wirklich unrealistisch,
fuer acon dieselbe Leistungssteigerung um etwa Faktor 5 zu erwarten, wie
wir sie fuer index.exe beim Uebergang vom 16 auf 32 bit erlebt haben?


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkyGy5QACgkQYhMlmJ6W47PCLAQAgBGYPo2A7nXsSR79bgUaZJ39
Q1Om5C2grtqgtCs7ukP3MCQnF1frzTCuW68KzA711VU6T2mCZroLPLqvT+S1GwdR
TBf7u9VMXxE6VCo1Ym2cR4meS1xqSZSNkTHPuXVnnwIkUyXTYd9nqKA2VBvGNuCO
CSyZe/ilBxUUQq+oxic=
=hIgc
-----END PGP SIGNATURE-----