[Allegro] acon-Beobachtungen

[Bernhard Eversberg]

Thomas Berger schrieb:
> 
>>> 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.
> 

Das liefert mir aber noch keinen Ansatzpunkt.

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

Stimmt, galt bisher aber nur für a99 (hätte in der Doku stehen müssen,
jaja). Wird in acon noch übertragen werden. Nächstes Release wird davon
frei sein, wie auch von dem |-Relikt.

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

Wie gesagt, das mit dem | wird aus acon expurgiert.

> 
>>> IV.
>>> 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).
>>
> 
> 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?
> 
Nein.

> 
>>> V.
> 
>> 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,
ist aber so, sorry. Hier was zu drehen wäre ne größere Sache, bei der
es garantiert wieder unerwünschte Nebenwirkungen gäbe. Da lassen wir
mal die Finger von.

> 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.
Das sind natürlich Lappalien.

> 
> 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
eben nicht, die Exportparameter bilden ja eine Klasse, das Exportieren
eines Satzes ist eine Methode.

> 
> Jedenfalls liefert diese Testvariante mit acon eine Laufzeit von ca. 5 Minuten
> die "Strafe" fuer lange Variablennamen,
Solche anthropomorphen Metaphern sind manipulative Sprache. Lange Namen
haben eben ihren Preis, nichts weiter, und $-Variablen womöglich einen
höheren als #u-Variablen - vielleicht aber auch umgekehrt - das wurde
noch nie evaluiert.

> 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?)
> 
Vielleicht, konkret fällt mir aber kein Ansatz ein, der viel bringen könnte.

B.E.