[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...
> 
> Die Schleifenkonstruktion müßte ich schon sehen. Es kommen tausendfach
> solche Konstrukte vor, die klaglos klappen, daher ist mir das suspekt.

Punkt I. war eigentlich nur als Hinweis darauf gedacht, dass unter SRCH
scheinbar(!) problemlos funktionierende Parameterdateien in acon einen
sichtbaren Fehler produzieren.


>> 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)".
> acon oder a99?
> Diese Zeilen allein produzieren kein Fehlverhalten, weder in a99 noch in
> acon, eben getestet. Es kommt also wohl auf den Zusammenhang an.

Momentan leider auch nicht mehr reproduzierbar. Allerdings faellt mir gerade
eine Unsauberkeit auf:

var "e-a"
xport param e-b
ins $errmsg
Write "ERROR: " $errmsg newline

liefert:
 Datei e-b. at pr existiert nicht
ERROR: e-a

lt. Dokumentation sollte eigentlich die Fehlermeldung in der iV vorliegen,
nicht der urspruengliche Inhalt.


>> 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?
> Ja bzw. nein, das ist plausibel. Aber es ist ein Relikt, das wir mal
> beseitigen sollten, d.h. a99 und acon davon bereinigen.

Danke. Stand der Diskussion vom Juni war m.E., dass in allen relevanten
Situationen die Repraesentation mehrerer Kategrorien simultan in der iV
im Format analog dem des Cstring kn erfolgen sollte, also mit ^J als
Feldtrenner.


>> 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.

> Das ist, sehe ich gerade, nur bei a99/acon der Fall, nicht bei SRCH.
> Sollten wir aber wohl korrigieren, d.h. auch SRCH sollte das so machen
> (und PRESTO), weil ja nicht beim Nachladen eines Satzes jedesmal erneut
> der Hintergrund auch verschoben werden sollte.

Das - ein in einer Anwendervariable aufbewahrter Inhalt, der erst nach
einer spaeteren Nachladung mit "zugehoerigem" #da ausgegeben wird -
koennte also das abweichende Verhalten von SRCH und acon erklaeren, das
muss ich pruefen.


>> Mit welcher "Magie" ueber
>> |i8 und |i9 besetzte #uxi korrigiert werden, weiss ich leider nicht).
>>
> Das sind #u-Variablen wie andere auch. Nur wenn sie im Moment des #da
> existieren, werden sie konvertiert. Kommt im nächsten Moment ein |i8,
> werden sie neu belegt (und "wissen" nichts vom vorangegangenen #da).
> 
> Zunächst: #dA ist überflüssig, wenn der Satz nicht zurückgespeichert
> wird, d.h. kein "put" folgt, denn dann bleibt ja das Ganze für die
> Datenbank folgenlos. Es ist nicht überflüssig, wenn nachfolgend mit
> demselben Satz abermals eine Ausgabe veranstaltet wird, die #da enthält.

Ein "neu belegtes" #uxi weicht also bezueglich Akzentvertauschung von
allen "aelteren" Kategorien und Anwendervariablen ab. Wie kann ich
das denn konsistent machen: Gebe ich #da, dann ist #uxi korrekt, aber
alles andere doppelt behandelt, ich muss also zuegig wieder #dA
geben, damit es wieder stimmt. Aber egal zu welchem Zeitpunkt ich #uxi
in eine andere Anwendervariable ueberfuehre, der Inhalt ist und bleibt
in Bezug auf die Akzentvertauschung immer inkonsistent mit allen anderen
Anwendervariablen. Sind |i8 und |i9 fuer einen Export mit Akzentvertauschung
ueberhaupt rettbar?


>> 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?
>>
> Dsa liegt daran, daß acon ein auf der Klassenbibliothek basierendes,
> objektorientiertes C++-Programm ist, SRCH dagegen ein konventionelles
> C-Programm, sehr kompakt und direkt programmiert. Objektorientierung
> hat ihren Preis, wie man bei Java am überzeugendsten sieht. index.exe
> ist, wie SRCH, konventionelles C, abgeleitet aus dem alten INDEX unter
> Weglassung aller Oberflächenaspekte (reines Konsolprogramm).

> Zum zweiten kommt wohl erschwerend hinzu, daß Ihr srch.job extrem
> opulent gestaltet ist, vernachlässigend, daß eine interpretierte
> Sprache (FLEX) mehr Zeit braucht, und daß sich lange Variablennamen und
> weiter unten liegende Sprungziele etc. bei hochfrequenten Schleifen
> dann umso hemmender bemerkbar machen. Ein Vergleich, ceteris paribus,
> mit "meinem" srch.job könnte aber erweisen, wer von uns beiden hier
> übertreibt. Wenn ich, dann überwiegt die Objektorientierung, und da dran
> können wir nun leider nicht weiter herumoptimieren.

Nun, der Flex/Job wird ja erst komplett eingelesen und dann erst
verarbeitet (vgl. die Argumentationen, warum ein "variables" Include
nicht funktionieren kann). Dass die Position einer Sprungmarke vom
Dateianfang gerechnet und damit mittelbar auch die Laenge der
benutzten Variablennamen einen Einfluss auf das Laufzeitverhalten
haben, scheint mir nicht zwingend, "normale" Optimierungen fuehre
ich eher dahingehend aus, dass die Zahl der Vergleiche etc. minimiert
wird. Ich gebe allerdings zu, dass "mein" srch.job sich den Luxus
leistet, die verarbeiteten Datensaetze mitzuzaehlen und auch bei
jedem 1000ten Satz einen diskreten "." ausgibt. Wenn das die
Performance so drastisch in den Keller ziehen sollte, ist etwas faul am
Flex-Konzept.

Ich habe zum Vergleich einmal dieselben Exporte statt mit der realen
Parameterdatei mit einer i-00.apr durchgefuehrt, die nur #00 plus
Zeilenvorschub ausgibt:

Fuer SRCH reduziert sich die Laufzeit von 34 auf 3 Minuten.
Fuer acon ist die Reduktion von 22 auf 7 Minuten.

D.h. der "Kern", also das Abarbeiten eines im Arbeitsspeicher vorbereiteten
Datensatzes hat durchaus noch den Hauptanteil gehabt, er ist in einer
32bit-Umgebung anscheinend um den Faktor 2 schneller (31 vs. 15 Minuten).
Das erscheint mir - die "Klassenbibliothek" scheint mir bei der
Interpretation von Exportparameterdateien nur am Rande beteiligt - gerade
im Vergleich zu index.exe doch sehr wenig.

Im Gegensatz dazu liess sich also der "Overhead", naemlich das Einlesen
des Rohdatensatzes, Anwenden des Suchbegriffs (etwa #00), mitzaehlen
der Saetze und Vorbereiten des eingelesenen Datensatzes im Arbeitsspeicher
auf 3 Minuten (SRCH) bzw. 7 Minuten (acon mit "meinem" srch.job) bestimmen.
Vergleich mit dem offiziellen srch.job ist leider nicht moeglich, der liefert
ziemlich prompt
J:<E111> -1 : fehlerhafte Eingabedaten

Ah:

fetch rec
// Ende?
if cancel jump fend

tut es nicht, ich muss
if error jump fend
ergaenzen (nachtraegliche Kontrolle der Ausgabe zeigt, dass die Resultate
identisch sind, der "error", der kein "cancel" war, trat also am Ende
der .ald-Datei auf)

Jedenfalls liefert diese Testvariante mit acon eine Laufzeit von ca. 5 Minuten
die "Strafe" fuer lange Variablennamen, Mitzaehlen von Datensaetzen, Ermittlung
des Satzstatus und Abfangen von Fehlerbedingungen ist also nicht gar so hoch
(bzw. wird dadurch kompensiert, dass "mein" srch.job den Schalter -F goutiert)

Fazit: Dass eine acon-Loesung beim "Overhead" tendenziell keinen
Geschwindigkeitsvorteil gegenueber dem festverdrahteten SRCH.EXE hat,
war zu erwarten (die Abarbeitung einzelner FLEX/Job-Kommandos ist
naturgemaess bremsend, die Beschleunigung durch das bessere IO-System
beim Einlesen der Rohdaten faellt nicht besonders ins Gewicht, zumindest
in diesen Tests, die keine v14-Ersetzungen nutzen). Gewiss gibt es in
vielen Einzelpunkten noch Optimierungspotential (vgl. etwa meinen neulich
geaeusserten Vorschlag zu "next srx", das nur diejenigen Datensaetze
ueberhaupt praesentiert, auf die der Suchbegriff zutrifft).

Von primaerem Interesse scheint mir aber die Beurteilung, ob der "Kern",
also das Abarbeiten von Exportparametern auf einen Datensatz inklusive
der dort erfolgenden Nachladungen, erwartungsgemaess beschleunigt wurde
oder ob hier noch optimiert werden kann (auch hier gibt es z.B. nicht
mehr den Zwang, Sprungmarken stets aufs Neue vom Speicheranfang an zu
suchen, aber vielleicht gibt es ja sogar innerhalb der bisherigen
Verarbeitungslogik Optimierungspotential?)

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

iJwEAQECAAYFAkyHVaAACgkQYhMlmJ6W47P7mwP+MQnZbJ/J6MQ5dSQ1Yl5GHID7
YQsYn/ThpRzPHa10RLn4G84N0uoYdDW5PCYHqiKzQ22tFhuJoqsJZokFXzNYKwD7
as13SHQ0LptQkx8RH/R5lFGZ8OmJReBZU10G7oPwTNnqPP9fu4EbUxyRdLElTumm
ZzWDRkNYXeAKpoD6Vlk=
=0mln
-----END PGP SIGNATURE-----