Maximalgrösse von Arrays

[Tom]

Hello,

Da das auf meine Nachfragen hin geschah, hab ich das auch mal aus dem Archiv rausgesucht.

Bitteschön: http://forum.de.selfhtml.org/archiv/2007/11/t161805/#m1053145

Dankeschön :-)

Das Ergebnis des Versuches hat mich doch selber ziemlich erschreckt.
Ca. 70 bis 100 Bytes Overhead pro Array-Element (numerischer Index). Das ist unvorstellbar schlecht implementiert. Bei "assoziativem Array" sind es noch mehr.

Und dann muss man auch noch überlegen, ob in der Local Descriptor Table nicht auch nochmal ein Overhead steckt. Ich nehme an, dass PHP (oder wohl besser C++) sich den Speicher extentwise vom OS beschafft und ihn dann intern selber zuteilt. Die 4-Byte-weise Zuteilung spricht jedenfalls dafür.

Das ist das alte Alloc-Modell, dass es schon zu Pascal-Zeiten gab.

Es ist dann manchmal zu überlegen, ob man nicht besser auf eine Datenstruktur mit statischen Typen ausweicht. Die könnte dann in PHP als "String" angelegt werden oder gleich als Random-Access-Datei. Da die ja ohnehin meistens doppelt gepuffert gelesen wird (bei den f-Funktionen im Gegensatz zu den dio-Funktionen, die nur einfach gepuffert lesen), dürfte das Programm bei lesenden Zugriffen gar nicht viel langsamer werden dadurch.

Spannend sind dann nur die schreibenden Zugriffe, wenn  ein flush() durch alle Schichten von Applikations-Interface, Hochsprachen-Interface, OS-Interface, Filesystem-Interface, Device-Interface bis auf die kleine magnetische Scheibe durchschlagen muss.

Wahrscheinlich habe ich sogar noch eins vergessen.

Wenn man dann bedenkt, dass die arme Festplatte für die Änderung eines einzigen Bits jedes mal mindestens einen ganzen Cluster lesen und schreiben muss, dann kann man schon verstehen, dass diesem Kerlchen etwas warm um den Actuator wird.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom