[Allegro] Indexproblem (erkannt?)

[Klaus Lehmann]

n Sat, 07 Jul 2007 22:26:29 +0200, Thomas Berger wrote:

guten morgen zum sonntag herr berger,



<cit>Ihre Zahl oben sagt 609kB
<cit>Ihre Zahl oben sagt 574kB.
danke, sie haben völlig recht. bin wieder der 1024'er zählung auf den
leim gegangen ;-




<cit>Logisch falscher Schluss. Ich habe einmal gemessen, wo im Bereich
<cit>zwischen 574 und 609kB es nicht mehr klappt. Die konkrete
.CFG-Datei
<cit>hat darauf durchaus einen Einfluss, wenn Sie 64.000 Bytes
<cit>Parameterspeicher aquirieren benoetigen Sie klarerweise 32.000
Bytes
<cit>mehr Arbeitsspeicher als wenn Sie sich nur 32.000 krallten.

gut, das bedeutet, daß ich das nur anwenden kann, wenn ich eine kleine
index-datei haben. dein eine index-api ist eine parameterdatei....
(oder?)




<cit>Vergleich zwischen Index.exe von v27.04 und dem von v27.01 zeigt,
<cit>dass die gebildeten II-Dateien etwa 27.000 Bytes kleiner sind,
<cit>insofern kann man schliessen, dass die neueren Index.exe bei
<cit>gleicher Konfiguration ca 26,5kB mehr Arbeitsspeicher benoetigt
als
<cit>die alte. Das ist durchaus dramatisch und m.E. mit Recht nicht
<cit>akzeptabel.

kann man wirklich so rückschliessen (naive frage?), wie groß die
ii-dateien, sogroß der verwendete ram-speicher. verblüffend....

ja, es wird langsam eng in unserem dos-fenster....

ist wirklich eine 32bit.variante von index.exe (jnd wrix.exe dann auch)
DIE lösung?
lässt sich nicht xms-speicher nutzen? (ems denke ich, ist wenig
sinnvoll..)





<cit>
<cit>Real kann ich aber bis herunter zur Grenze von 593kB (607.000
Bytes)
<cit>freiem Arbeitsspeicher indexieren (Groesse der II-Dateien schwankt
<cit>stark zwischen 32.000 und 40.000 Bytes), danach schafft es
index.exe
<cit>nicht mehr, die Aufrufzeile fuer qrix zusammenzubasteln (und
demzufolge
<cit>wird auch keine qs.bat erzeugt ;-)

moment... nur ergänzt.
ich habe vielleicht vergessen zu berichten, daß es nicht an qrix liegt.
der erste aufruf von idnex.exe (so hat auch h. fischer berichtet?!)
gehts in ram-nirwana: "kein ram zur verfügung, wieviel datensätze
hätten's denn gern?"




<cit>> nun, wer seine installationen inschuss hält, wird die config.nt
kennen,
<cit>> und wissen, was da alles nötig ist, und was nicht. auch wenn er
hier
<cit>> einige stellschrauben dreht, wird er es nicht hinbekommen. ich
komme
<cit>> z.b. NICHT über die (s.o.) 587kb hinüber. keine change. DAS
ist (m)ein
<cit>> hardware-problem. das remmen des ansi-treiber bringt keine
entlastung! 
<cit>
<cit>Ich kann immer nur raten, die config.nt auf der werksseitigen
Setzung
<cit>zu lassen, hoechstens noch den Wert fuer "files" von 20 auf 30
<cit>hochzusetzen...

hm. das dos-alf benötigt aber mehr.
ich setze es imem auf das maximum von 99....
und: wenn mann auch noch vor jedem index-vorgang die config.nt
verändert. 

[hatte es gestern mal wieder mit einem äusserst restriktiven netz zu
tun (keine fonts, keine config.nt, keine vernüünftige temp-variable;
oberschlaue winserver-admins hatten alles abgesperrt; aber mit VNC
arbeiten!!!!! DAS weiss BESTIMMT der pesonalrat NICHT!]

für mich ergo: wenn man anfangt, die optimalen cfg-werte, config.nt und
was es sonst noch alles gibt, auf KNAUTSCH zu setzen, dann kommen sie
garantiert woanderes (z.b. alf-dos) in die mistgrube... ;-(
also: die optimum-werte belassen.




<cit>> die entlastung, die benötigt wird (IN dem hardware-fall wie bei
mir),
<cit>> wäre eine reduzierung des ram-bedarfs bei index.exe um
vermutlich
<cit>> 40kb!!!
<cit>
<cit>s.o.: Ein PC der vorher an der Grenze war, ist nun ca. 26,5kB
<cit>von der Grenze entfernt...

gut, das entspricht ja ungefähr meiner beobachtung.




<cit>> info: es spielt KEINE rolle, ob die werte in der cfg, api weiter
<cit>> runtergeschraubt werden, oder einträge in massen IN der api
gelöxcht
<cit>> werden, die neue index.exe benötigt dieses groà es dos-fenster.
<cit>> die index.exe von 2005 verkraftet umfangreiche api's und oder
cfg's.
<cit>
<cit>27.000 Bytes sind durchaus in der Groessenordnung, dass man sie
<cit>durch Tunen der .CFG-Setzungen noch herausschinden koennte, gerade
<cit>die a99-basierten Indexierungsmethoden treffen allerdings
keinerlei
<cit>Vorkehrungen fuer die Indexierung mit einer alternativen
.CFG-Datei.


in der letzten ergänzungsmail erwähnte ich die index.exe vom 20.6.07
(qrix analog); damit klappte es auc  mit der nachbarin ;-)



<cit>
<cit>Weil das eigentliche Executable index.exe sogar 2kB kleiner ist
<cit>als in frueheren Versionen, scheint mir der zusaetzliche
<cit>Speicherverbrauch also weniger an zusaetzlichem Programmcode fuer
<cit>das Multix-Feature zu liegen, sondern am Preallozieren von
<cit>Datenstrukturen fuer die eventuelle Multix-Nutzung. Es faellt
<cit>allerdings auch auf, dass die (leider fehlerbehafteten) index.exe
<cit>von v27.02 und v27.03 immerhin 10kB groessere II-Dateien
produzieren,
<cit>was mich hoffen laesst, dass das aktuelle Index.exe noch ein
<cit>gewisses Optimierungspotential hat...

h. eversberg, bitte unbedingt optimieren....
danke.


viele grüße
ihr klaus lehmann