[Allegro] a99 : Entschleunigung wieder entkräftet

[Bernhard Eversberg]

Am 04.12.2014 09:45, schrieb Thomas Berger:
>
> Sie hatten den Code dazu m.W. nie veroeffentlicht (ist allegro nicht
> eigentlich inzwischen Open Source?),
Schon, aber an dieser Baustelle wollte ich noch dies und das aufräumen
bzw. besser verständlich kommentieren, daher habe ich es noch
zurückgehalten.

> daher kann ich nur spekulieren:
>
> * Kann (ich vermute: Zugriff auf den naechsten Schluessel liefert ein
>    unerwartetes Ergebnis) nicht erkannt werden, dass *Bedarf* fuer
>    einen Re-Scan besteht
Je nun, diesen Bedarf zu *erkennen*, das ist eben das Problem.

>    Bzw. (ich spekuliere) kann nicht einfach die gesamte Kachel des
>    Index (2kB?) an der Stelle eingelesen werden
Es gibt da kein "Kachel"-Konzept bzw. keine Routine, die so ein Einlesen
und nachfolgendes ermöglichen würde. Die Sequenz von Schlüsseln kann
an jeder Stelle plötzlich unterbrochen sein und dann das Einlesen eines
anderen Blocks nötig machen. Es ist weitaus diffiziler als man denkt.

>
> * Anwender haben mir Hinweise darauf gegeben, dass insbesondere der
>    Wechsel des Registers problematisch ist und zu Abbruechen vor oder
>    bei der ersten gezeigten Zeile im Index fuehrt.
So etwas habe ich noch nicht erlebt, falls es mal nachvollziehbar
dokumentiert wird, kümmer ich mich drum.

>
> Sie koennten ausprobieren, die fraglichen Kacheln direkt zu
> locken ...
Solche Eingriffe würden mehr Zeit erfordern, als ich momentan
erübrigen könnte. Der Zugriff auf die "Kacheln" ist eine sehr in
der Tiefe liegende Sache (in den aindex-Quelldateien).

(Leseversuche auf die jeweilige Kachel fuehren dann
> zu drastischen Fehlern bzw. evtl. laesst sich dem Aufruf mitteilen,
> dass er 100ms Zeit fuer den Zugriff hat und ein Lock abwarten
> kann), und/oder die Lesezugriffe so umzustellen, dass sie sich
> am Range-Locking der Schreibzugriffe beteiligen: Das ist zwar
> immer noch eine bremsende Aktion, aber viel spezifischer und
> auch leichtgewichtiger als eine Datenbanksperre (Range-Lock
> auf .TBL-Datei-Byte, Sperrvermerk in die .TBL-Datei schreiben,
> Range-Lock aufheben, Operation, Range-Lock auf .TBL-Datei-Byte,
> Entsperrvermerk in die .TBL-Datei schreiben, Range-Lock aufheben
>
Ja, hört sich ganz einfach an. Solche Range-Locks sind aber sehr
mit Vorsicht zu genießen wegen möglicher Zwischenfälle und
Nebenwirkungen, an sowas geht man nicht gerne ran.

>
> Ist das Index-Zeigen wirklich so verschieden vom Find-Zugriff
> in den Faellen, wo Trunkierung eingestellt ist? Oder ein acon-
> qrix-Kommando mit eingestellter Restriktion?
>
Ja, weil hier keine Ergebnismenge gebildet wird, sondern nur konsekutiv
gelesen.

> Aber in einer Situation, wo selbst im Normalfall durchaus
> "viele" Schluessel auf einen Rutsch zu lesen sind, sollte doch
> eine Optimierung moeglich sein?
>
Schon denkbar, aber im Momet nicht machbar, fürchte ich, jedenfalls
nicht für V34.8, und die muß raus...

B.E.