std::list ist ja im prinzip eine stink normale verkettet bzw. doppel verkette list dessen elemente unterschiedliche typen behinhalten können. Welche Optimierungen wurden bei der implementation der std::list getroffen, das sie schneller ist als ne eigen progammierte verkettet list?

BorisDieKlinge schrieb:

Hallo ihr,

std::list ist ja im prinzip eine stink normale verkettet bzw. doppel verkette list dessen elemente unterschiedliche typen behinhalten können. Welche Optimierungen wurden bei der implementation der std::list getroffen, das sie schneller ist als ne eigen progammierte verkettet list?

std::list ist also template aufgebaut. dementsprechend hast du einsicht in den source. kannst also angucken was die anders machen als du.
wenns um reine preformance geht sind die std::container nicht umbedingt das performanteste. haengt jedoch auch jeweils von der implementierung ab.
wenn man auf bestimmte gegebenheiten und datentypen eine eigene liste implementiert, kann die durchaus performanter sein als die std::list.

Meep Meep

Hallo ihr,

std::list ist ja im prinzip eine stink normale verkettet bzw. doppel verkette list dessen elemente unterschiedliche typen behinhalten können.

Üblicherweise gibt der Template-Parameter den Element-Typ an. Das heisst,
STL-Container enthalten Elemente gleichen Typs.

Die Größe ist variable... man kann auch nich sagen in welchem bereich sich die anzahl der elemente bewegen...

es muss möglich sein schnell elemente in mitten der liste zu löschen bzw. anfügen..

Welche Optimierungen wurden bei der implementation der std::list getroffen, das sie schneller ist als ne eigen progammierte verkettet list?

Keine, weil das eine sinnlose Frage ist. Einerseits ist std::list aus sich des Standards nur eine Spezifikation, jede Form von Optimierung demzufolge eine Frage der konkreten Implementierung (demzufolge müsstest du schon die konkrete Standardbibliothek, auf die du dich beziehen willst, angeben). Zudem setzt ein solcher Vergleich voraus, das es diese "eigene programmierte List" bereits gibt, damit man relativ zu dieser optimieren kann. Eine Implementation der Standardbibliothek muss eine gute Lösung für sehr viele Programme bieten, häufig ist es bei extremen Optimierungen so, dass diese bestimmte Operationen auf Kosten anderer Operationen optimieren - das setzt aber eben Kenntnis der beabsichtigten Nutzung voraus, um damit netto einen Vorteil zu haben. Zudem lassen die Spezifikationen der Container (jedenfalls die der sequentiellen Container) wenig Spielraum - es ist nicht zu erwarten, dass eine gute eigene Implementierung, die gleiche Komplexitätsgarantien hat, gegenüber dem Standardtemplate signifikante Performancevor- oder nachteile hat (es mag eine kleine Ausnahme geben, wenn man selbst Movesemantik implmentieren kann - dafür gibt es gegenwärtig keine portable und generische Lösung). Nicht zuletzt gehen Probleme in diesem Bereich häufig auf den verwendeten Allokator zurück, und es ist völlig klar, das eine einzelne Allokatorstrategie nicht in allen Anwendungen optimale Performance bieten wird. Das ist dann aber eigentlich keine Frage des Containers als solchem.

Nicht zuletzt gehen Probleme in diesem Bereich häufig auf den verwendeten Allokator zurück, und es ist völlig klar, das eine einzelne Allokatorstrategie nicht in allen Anwendungen optimale Performance bieten wird. Das ist dann aber eigentlich keine Frage des Containers als solchem.

Es hat vielmehr rein garnichts mit dem verwendeten Container zu tun, da der nur einen vorgegebenen Allocator benutzt. Die Allocator-Strategie kann also von aussen per Templateparameter vorgegeben werden ohne was an der Implementierung des Containers zu aendern.