F: Datei-gezieltes Indexieren

[Thomas Berger]

Michael Lackhoff wrote:

> Das geht schon jetzt, wenn nicht alle Dateinummern gebraucht werden.
> Mit 101 und 111 waere nicht ein Dateiname (jeweils ohne Erweiterung)
> Teilstring des anderen. Offensichtlich funktioniert der -D-Parameter
> allegrotypisch wie mit * am Ende. Das gilt uebrigens nicht nur fuer
> index. Ich habe mich auch schon mal mit srch reingelegt: Ich wollte
> den Inhalt von test.mlg weiterverarbeiten und hatte noch eine Datei
> test1.mlg im Verzeichnis. Anschliessend wunderte ich mich dann, dass
> die Ergebnisdatei doppelt so gross war wie erwartet.

Ich hatte einmal - um bei Ihrem Beispiel zu bleiben - auch
noch ein Verzeichnis test dort - Das Ergebnis war ziemlich
verwirrend :-)

Es wuerde vermutlich ausreichen, wenn man 

-d test_1.ald

schreiben duerfte, derzeit wird ".ald" einfach ignoriert und
der Suchbegriff ist

test_1*.a??


> Zu den ganzen Posts zu Tricks mit Index habe ich aber auch noch eine
> Frage: Hat schon jemand eine gute Moeglichkeit gefunden, die
> Optimierung von Parameterdateien mit irgendeiner Form von Benchmark
> zu testen und damit voranzutreiben? Alles, was mir bisher einfaellt
> ist zu ungenau, um den Geschwindigkeitsunterschied kleiner
> Aenderungen zu testen, deren Summe ja meist erst viel bringt.

Nach meinen Erfahrungen kommt man mit gesundem Menschenverstand
ziemlich gut hin, was die Optimierung innerhalb kurzer Codesegmente
angeht. Schwierig wird es dabei, in Indexparameterdateien den
Effekt abzuschaetzen, den die Lage der Sprungmarken hat.

Ich habe dazu ein Tool, das mir eine Kategorienstatistik einer
gegebenen Datenbank liefert. Mit dessen Ergebnissen kann ich
dann abschaetzen, wie oft durchschnittlich pro Datensatz ein
jeder ak-Sprung ausgeloest wird.

Desweiteren habe ich ein Tool, das mir zu einer gegebenen
Parameterdatei bzw. Includetabelle abschaetzt, wieviel 
Parameterspeicher gebraucht wird.

Multipliziere ich also die Haeufigkeit eines ak-Sprungs (oder
Unterprogrammsprungs) mit der Laenge des vor der Sprungmarke
(bzw. zwischen Aufruf und Einsprung) liegenden Codes, bekomme
ich die "Kosten" heraus: zwar nicht der Abarbeitung, aber der
toten Spruenge.

Dann setze ich mich mit dem Editor hin und bastle mit einem Modell
der .cPI: Ich trage von allen ak-Spruengen und Unterprogrammen 
die Haeufigkeiten ein und die Namen der Includetabellen und
deren Speicherbedarf und rechne mit einem dritten Tool die
Gesamtkosten aus (bzw. nehme einen Teil heraus und lasse ihn
mit dem Tool an die Kostenminimale Stelle einsortieren).

Erfahrungsgemaess kommen mit dieser halbautomatischen Methode
starke Beschleunigungen heraus, der Arbeitsaufwand ist aber
immer noch enorm. Wie gross diese Beschleunigungen tatsaechlich
sind, ist schwer zu sagen, bislang habe ich jedesmal waehrend 
des Eintragens der Haeufigkeiten fuer die ak-Spruenge irgendeine
Stelle entdeckt, wo ich eine ganz entlegene Sprungmarke unbemerkt
(da in der Regel sofort agebrochen wurde) ausserordentlich oft 
ansprang...

Frueher einmal habe ich mit dem Editor riesige, homogene Daten-
und Parameterdateien erzeugt, um auszurechnen, wieviel Zeit
es kostet, bestimmte Befehle (z.B. kurze relative Spruenge)
auszufuehren: Es wurde dann einige zigtausend mal dasselbe gemacht
und ich konnte gut mit der Uhr messen. Aber fuer reale Bedingungen
wird man (wegen des Einflusses auf die Geschwindigkeit nachfolgenden
Codes) eigentlich im Zweifel einer speicheroptimierten Codierung den
Vorrang vor einer schnellen Ausfuehrung geben...

Gruesse
Thomas Berger