Da widerspreche ich auch nicht. Es ist allerdings kein wesentlich Faktor weil es andere Baustellen gibt der mehrere Größenordnungen langsamer sind. Wenn ich Performance optimiere fange ich nicht bei dem Teil an der sowieso schon am schnellsten sein wird.LukeNukem hat geschrieben: ↑Donnerstag 8. Juli 2021, 16:12 De facto ist es nun einmal auch so, daß wir gar nicht wissen, wie die Netzwerkanbindung des TO ist, wie die Serverseite aussieht, und, vor allem: wie die Daten aussehen. Aber das das hier:
mehrmals dieselben Zugriffe auf dasselbe Dictionary macht, währendCode: Alles auswählen
d['a']['b']['c'].get('eins') d['a']['b']['c'].get(''zwei') d['a']['b']['c'].get('drei') d['a']['b']['c'].get('vier')
sich diesen Unfug spart, ist für einen Profi wie Dich sicherlich offensichtlich und dürfte mit wenigen Sekunden des Nachdenkens sogar einem Hobbyisten klar werden.Code: Alles auswählen
dummy = d['a']['b']['c'] dummy.get('eins') dummy.get(''zwei') dummy.get('drei') dummy.get('vier')
Könnte man wenn man von Python keine Ahnung hat, aber da keine Kopie angelegt wird sondern nur eine Referenz führt dass garantiert nicht zu einer Allokation.Nun könnte man zwar vermuten, daß die zweite Variante eine neue Speicherallokation provoziert[...]
Das Copy Modul existiert um Objekte zu kopieren, ist größtenteils unnötig und spielt hier keine Rolle da es nicht benutzt wird (und auch nicht werden sollte). Das Betriebssystem hat da wenig beizutragen zum einen weil diese Optimierungen den Speicherverbrauch gering halten und sich auf die Laufzeit, was ja hier das Problem ist nicht auswirken, zum anderen funktioniert Copy-on-Write jetzt eher nicht so gut wenn man ständig in irgendwelche Objekte schreibt wie man dass bei Reference Counting so macht.[...], allerdings... einerseits optimiert Python hier schon ziemlich gut (warum gibt es eigentlich das Modul "copy"?) und auf der anderen Seite hat da womöglich auch das Betriebssystem bzw. dessen Speicherverwaltung noch etwas beizutragen, etwa mit Copy-On-Write und Same-Page-Merging.
CPython hat einen eigenen Memory Manager der für Allokationen genutzt wird. Der baut auf malloc auf und somit ist tief unter der Haube irgendwo ein malloc versteckt wird aber i.d.R. nicht passieren wenn man ein Objekt erstellt. Damit unterscheidet sich Python da wesentlich von Sprachen wie C, C++ oder Rust wo man bei einer Heap Allokationen normalerweise ein malloc hat. Das ist auch essentiell für die Performance einer solchen Sprache wo man anders als in C, C++ oder Rust nahezu alles auf der Heap statt auf dem Stack allokiert. Die JVM ist hier ein besonders gutes Beispiel, da die sich gleich beim Startup eine ganze Heap allokiert um zur Laufzeit möglichst nie malloc aufzurufen.Darüber hinaus, bitte verzeih' den Widerspruch: Python nutzt unter der Haube selbstverständlich die ganz normale malloc(3)-Funktion. Daß Python dessen Benutzung stark optimiert (wie gesagt, think "copy"-Modul), ist diesseits bekannt. Aber trotzdem danke für den Hinweis, der für andere Leser vielleicht wertvoll ist.
