[Allegro] update.exe / 32 bit

[Bernhard Eversberg]

Am 21.12.2011 21:54, schrieb Andreas Wolf:
>
> nur damit keine Mißverständnisse entstehen: Meine Ausrufezeichen waren
> Zeichen der Hoffnung, daß, nachdem es nun import/32bit, srch/32bit sowie
> einen funktionierenden VuFind-Opac gibt, vielleicht auch für den letzten
> Punkt eine Lösung gefunden werden könnte, und kein Ausdruck der Kritik.
>
Achso, na dann sorry, bei mir war's als Exklamation des Unwillens 
angekommen.
Ein update32, das (und nicht nur das) hat Berger ganz richtig
eingeschätzt, wäre in punkto Performance viel weniger interessant als
srch32, wo der Gewinn sehr beträchtlich ist, auch gegenüber srch.job.
Das liegt daran, daß srch.job quasi alles selber macht, eben in der
FLEX-Sprache, und die ist als Interpretersprache deutlich langsamer
als ein .exe wie eben srch32.exe. Der update.job dagegen macht fast nur
das Einlesen der Daten, die aufwendige Indexarbeit und das Speichern
der Daten macht acon.exe intern. Deshalb ist, wie jetzt nochmal in einem
Test ermittelt wurde, "acon -jupdate" um gut 40% schneller als
update.exe! Hier gehört, denke ich, schon ein Rufzeichen hin, und auch
das kann daher schon eine Motivation sein, darauf umzustellen. Bei den
gängigen Aufrufen klappt der Ersatz von "update" (oder seit 2010 "upd")
durch "acon -jupdate" klaglos, wie wir ebenfalls nochmal verifiziert
haben und in den von uns verbreiteten Batchdateien deshalb auch
jetzt endlich einbauen werden. Sind aber nur 5.
Und noch einen Grund gibt's dafür, wie sich zeigte: In downgeloadeten
Pica-Daten, aber wohl auch sonstwo, kommen Anreicherungen wie
Abstracts und Inhaltsverzeichnisse vor, die eine Länge von 10.000 Byte
überschreiten. update16 verendet dann, "acon -jupdate" nicht. Und
unterhalb dieser Grenze liefert es, auch das wurde nochmals verifiziert,
exakt dasselbe Ergebnis wie update16, aber schneller.

 > Wie auch immer: Müssen wir, 'meine' Bibliotheken und ich, eben acon
 > und die update.jobs zum Einsatz bringen.

Fangen Sie damit mal gleich an und geben Sie Rückmeldung, ob's bzw. was
nicht klappt.
Tip: Besorgen Sie sich ein grep-Progrämmchen und machen Sie dann sowas
wie   grep \\upd *.bat  und  grep update *.bat, um alle Batchdateien
schnell zu finden, in denen relevante Aufrufe vorkommen. Aber wem sage
ich das. "Aufwand" kann man das nicht wirklich nennen. Bergers Jobs
sind teils von ganz anderem Kaliber, vor allem weil er mittels
zusätzlichen Exporten etc. während des Updates herumtrickst und das
System bis an seine Grenzen ausreizt. Gleichwohl hat er's geschafft,
das alte update durch seinen update.job damit zu ersetzen, und seit
Monaten läuft's damit rund.

NOCH eine andere Variante, die man schnell realisieren könnte und
die auch schon mal vorgeschlagen wurde: Ein ganz kleines Programm
namens "update.exe" schreiben, das folgendes tut: Wenn man es z.B. mit
dem Befehl startet
update -fm41 -ddemo2 -bcat -n2 -udaten.alg -m0 -F -e.../...
   dann erzeugt es folgenden Befehl:
acon -jupdate -fm41 -ddemo2 -bcat -n2 -udaten.alg -m0 -F -e.../..
und startet diesen (in C mittels system("acon ...")).
Dann können Sie Ihren Anwendern beim nächsten Software-Update dieses
neue update.exe unterjubeln, und das war's dann schon. FALLS und
WENN dann noch ein update32 kommen SOLLTE, nun, dann liefern Sie
das als update.exe aus, und sind endgültig über'm Berg.

>
> Die meisten Bibliotheken werden sich zunächst und einstweilen lieber einen
> PC auf 32bit zurücklegen.
>
Und wer bräuchte schon wirklich 64bit? Aber die Industrie wird bald
nichts anderes mehr liefern, schon wahr. Was "allegro" betrifft, so
haben die 64bit jedenfalls ihren Schrecken nun endgültig verloren.

B.E.