Max. Anzahl Datensaetze

[Roland Henkel]

Liebe Liste,

- die Beschränkung auf N = 2**n würde m. E. zu unnötigem Verschnitt führen,
vor allem bei größeren n. Vor allem läßt sich bei Bedarf die max. Anzahl nur
sehr ungenau regulieren. nach N=8 käme schon N=16. Man kann leicht in die
Lage kommen, daß 8 etwas zu eng und 16 viel zu reichlich bemessen ist.
- Die Multiplikation die man durch das shiften einspaart, wird dann wieder
durch das 5-stellige TBL-Entry und die Notwendigkeit, dieses erst zu
zerlegen zunichte gemacht. 4-stellige Entries kann man ohne weiteres in ein
Register laden und das Dateinummern-Byte ausblenden. 4 Byte sind Worte, die
manche Operation vereinfachen (z.B. auch die Bildung des TBL-Offsets
aus der Satznummer (also x 4), die wahrscheinlich jeder anständige Kompiler
ohnehin durch ein shift ausführen lassen wird. x 5 wäre dagegen eine
handfeste Multiplikation.

Zuguterletzt kann ich mir es nicht verkneifen, meinem Empfinden Ausdruck zu
geben, daß die vorgeschlagene Methode, die max. Anz. Datensätze zu erhöhen,
eine von jenen, relativ seltenen Ideen und Eingebungen ist, an denen man
(zumal, wenn man mal selber mal programmiert hat)  eine förmlich ästhetische
Freude empfinden kann. Einfach, wirksam, rund, und die Konsistenz des
bestehenden nicht berührend, sondern fortschreibend.

MfG
R. Henkel
_________________________________________________________________
 Roland Henkel          Email: roland.henkel at sbb.spk-berlin.de

 Staatsbibliothek zu Berlin
 D-10102 Berlin

 Abt. IB
 Tel.   (030) 2661393
_________________________________________________________________

----- Original Message -----
From: Ralf Matalla <matalla at CDMAIL.UB.UNI-DUESSELDORF.DE>
To: Diskussionsliste Allegro-C <allegro at buch.biblio.etc.tu-bs.de>
Sent: Tuesday, November 16, 1999 2:06 PM
Subject: Re: Max. Anzahl Datensaetze


> Langsam bekommt ja Einblick in die Details!
> Deswegen gebe ich ein _letztes_ Mal zu bedenken:
>
> > sondern man nimmt die Satznummer mal 4 und gelangt zur TBL-Position,
> > daran aendert sich nichts. Und dort steht zuerst die Dateinummer,
> > das aendert sich auch nicht, und die naechsten 3 Byte rechnet man in
> > den Offset um, und dann nimmt man mit N mal (bis jetzt ist N=1) und
> > erhaelt den wirklichen Offset.
>
> Mit einem Byte fuer die Datei plus vier Byte (statt bisher drei)
> aendert sich am oben beschriebenen Prinzip nicht viel: man nimmt mal
> 5, gelangt zur TBL-Position, Dateinummer, dann 4 Byte fuer den Offset
> - und keine Multiplikation.
> Vor allem: in der TBL steht als erstes Byte ohnehin eine 3: das neue
> Programm liest einmal diese drei und weiss: eine 'alte Datenbank',
> drei Byte Offset. Neue Programme schreiben eine 4 dorthin und
> wissen auch Bescheid. Der Anwender dagegen braucht gar nichts zu
> wissen und zu tun. _Scheint_ mir einfacher.
>
> Ansonsten: noch einmal an alle, was ich irrtuemlich privat an H.
> Eversberg schrieb:
> Ich denke, auch wenn die Zugriffe 'selten' sind, sollte weiterhin
> alles fuer eine Beschleunigung des Programms getan werden (srch mit
> Nachladen bringt den Rechner auch zum Arbeiten). Da Multiplikationen
> bzw. Divisionen i.a. erhebliche Rechenzeit kosten, solche um einen
> Faktor 2 aber nur eines Shifts beduerfen, spricht gegen obige
> Anregung die Aenderung der Multiplikation von 'mal 4' auf 'mal 5'.
> Dafuer wird eine Multiplikation eingespart.
>
> Eine Beschraenkung des Original-Vorschlags auf Vielfache von 2 (also
> N=4 oder N=8) aber macht den Zugriff sicher schneller.
> Im Alltag (z.B. editieren) wird es sich sicher nicht auswirken - aber
> wenn man fleissig nachlaedt?
>
> Wie auch immer, langer Rede, kurzer Sinn: Ich sag's nur mal und
> begruesse beides.
>
> Ralf Matalla
>
> Universitaets- und Landesbibliothek Duesseldorf
> IVS- und CD-ROM-Koordination
> Fachref. Mathematik u. Datenverarbeitung
> Universitaetsstr. 1
> 40225 Duesseldorf
> Tel.: ++49 211 81-13527
> Fax:  ++49 211 81-13054
>