[Allegro] Indexproblem (erkannt?)

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo Herr Lehmann,

> meine erkenntnisse:
> ===================
> 
> auf dem laptop (wxp-ibm)
> sagt mem, im cmd.fenster:
> 655360 konv. speicher
> 587648 max größe für programm
> ~~~~~~~
> 
> auf einem stationären pc (wxp)
> sieht es so aus:
> 655360 konv. speicher
> 623728 max größe für programm
> ~~~~~~
> 
> 
> [nebenbei bemerkt:
> =================
> es gibt zwei commando-zeilenfenster:
> cmd.exe und command.com
> also, aufpassen, WO man das mem.exe ausführt. in einem
> dos-(command.com)-fenster ist der freie platz etwas kleiner, als in
> einem aufgerufenen cmd-fenster....]

mem.exe sagt immer etwas ueber die zugeordnete NTVDM aus...



> 1. PC
> mit allen alten und neuen index-versionen (auch die vom 4.7.2007)
> habe ich auf dem stationären pc keine probleme. der index-vorgang läuft
> zweistufig sauber ab.
> 623kb für die index.exe reichen demnach aus.

Ihre Zahl oben sagt 609kB


> 2. laptop
> auf dem ibm-laptop, welches nur 587kb zur verfügung hat, läuft seit ca

Ihre Zahl oben sagt 574kB.


> 1-2 monat3n keine moderne index.exe mehr ab.
> die fehlermeldung sieht in etwas so aus, wie h. fischer sie beschreibt:
> "nicht genug konventioneller arb.speicher zur verfügung" usw usw.
> 
> wenn der laptop wie beim stationären wxp-pc seine üblichen 623kb zur
> verfügung hätte, würde der index.exe auch funktionieren, da bin ich
> sicher.
> 
> wenn ich alte index.exe und (hat es was mit qrix zu tun?) qrix.exe
> verwende, dann habe ich keine probleme (auf dem laptop!): index.exe
> 204480   05.10.11   11:24 (qrix analog) 
> 
> 
> 
> 
> diverse ergo's:
> ===============
> 
> ergo: das problem ist hausgemacht!
> mein laptop ist dran schuld, das ein modernes index.exe NICHT läuft.
> 
> ergo2: jeder pc, der nicht die vollen 623kb zur verfügung hat, da wird
> das moderne index.exe NICHT laufen.

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

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

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


> nun, wer seine installationen inschuss hält, wird die config.nt kennen,
> und wissen, was da alles nötig ist, und was nicht. auch wenn er hier
> einige stellschrauben dreht, wird er es nicht hinbekommen. ich komme
> z.b. NICHT über die (s.o.) 587kb hinüber. keine change. DAS ist (m)ein
> hardware-problem. das remmen des ansi-treiber bringt keine entlastung! 

Ich kann immer nur raten, die config.nt auf der werksseitigen Setzung
zu lassen, hoechstens noch den Wert fuer "files" von 20 auf 30
hochzusetzen...


> die entlastung, die benötigt wird (IN dem hardware-fall wie bei mir),
> wäre eine reduzierung des ram-bedarfs bei index.exe um vermutlich
> 40kb!!!

s.o.: Ein PC der vorher an der Grenze war, ist nun ca. 26,5kB
von der Grenze entfernt...


> info: es spielt KEINE rolle, ob die werte in der cfg, api weiter
> runtergeschraubt werden, oder einträge in massen IN der api gelöxcht
> werden, die neue index.exe benötigt dieses großes dos-fenster.
> die index.exe von 2005 verkraftet umfangreiche api's und oder cfg's.

27.000 Bytes sind durchaus in der Groessenordnung, dass man sie
durch Tunen der .CFG-Setzungen noch herausschinden koennte, gerade
die a99-basierten Indexierungsmethoden treffen allerdings keinerlei
Vorkehrungen fuer die Indexierung mit einer alternativen .CFG-Datei.

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


viele Gruesse
Thomas Berger


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGj/b1hKFJT0F1FsoRAsHqAJ9RQVDGlTN9hWcpq7T9UiNBhqGUQACfdjeV
Fi3NZOt6F65AGSt1C9AfdWY=
=z+W3
-----END PGP SIGNATURE-----