nicht angemeldet
Hi,
So ganz ist mir die Notwendigkeit noch nicht klar.
Das hat sich inzwischen nur in sofern geändert, dass mir jetzt noch weniger klar ist, was du wirklich erreichen willst ...
Warum muss #container durch einen Wrapper ersetzt werden, warum kannst du nicht #container wie gewünscht formatieren?
Weil ich via JS die Höhe des gesammten Inhalt ermitteln will, und es ist bedeutend schneller nur von einem element die offsetHeight abzufragen, als von jedem einzelnen, zumal auch noch margin's mit in die höhe einfliessen sollen.
Und warum reicht dir dann die offsetHeight von #container nicht, warum müssen die Elemente erst in #wrapper umgehängt werden?
Schon möglich, dass da noch weitere CSS-Eigenschaften im Spiel sind, die das unmöglich machen - aber ohne, dass du konkreter wirst, kann ich dir da auch nicht mehr viel Tipps geben oder Vorschläge machen.
Ein Online-Beispiel nebst Erklärung, was *wirklich* ermittelt werden soll und zu welchem Zwecke, könnte dem Verständnis vermutlich noch am ehesten weiterhelfen.
Das dachte ich mir bereits und stimmt die zusätzliche abfrage ist langsamer, allerdings ist diese Methode immernoch schneller als das Array umzudrehen und dann alles hinten anzufügen :)
Welches Array denn "umdrehen"?
Generell gilt: DOM-Manipulationen gehen idR. immer schneller, wenn sie "ausserhalb" des DOMs des aktuellen Dokumentes stattfinden.
#container auch erst aus dem Dokument herauszulösen (removeChild), bevor dessen Kindknoten "entnommen" werden, könnte ggf. noch etwas bringen. (Sofern vom Ablauf her möglich; kann ja auch danach wieder engefügt werden, wenn nötig.)
Ja daran hatte ich noch gar nicht gedacht, aber ich probier da mal ein bisschen rum, wahrscheinlich bringt das dann auch noch mal nen ganzes Stück
Nein, das kannst du wieder vergessen, wenn du die Maße von Elementen ermitteln willst - wenn diese nicht im DOM hängen, haben sie auch keine Maße (IIRnottotallyinC)
Von einer while-schleife sehe ich i.d.R. ab, da sie oft langsamer ist als eine for-schleife, allerdings ist dies ja bei JS nicht unbedingt der Fall,
Warum sollte die generell langsamer sein?
Beide Schleifen haben jeweils eine Bedingung zu überprüfen und davon abhängig zu entscheiden, ob sie weiterlaufen, oder nicht.
(Im Bereich der erwähnten "Micro-Optimierung" gilt dann für for-Schleifen allerdings wieder, der pre-increment- bzw. pre-decrement-Variante den Vorzug vor der entsprechenden post-Variante zu geben. i-- muss erst eine "Hilfsvariable" anlegen, die den Inhalt der Variablen *vor* der Dekrementierung aufnimmt, weil dieser den Rückgabewert des Ausdrucks i-- darstellt - bei --i hingegen ist der um eins verringerte Wert von i direkt auch der Wert des Ausdrucks, so dass die Zwischenspeicherung des aktuellen Wertes von i entfällt.)
Aber mir ist auch noch meine äußerst dämliche Kurzsichtigkeit aufgefallen, denn die create-funktion ist ja "rough and ready" und dabei mach ich eine ziemlich dumme Abfrage:
...
if(typeof(attr[i]) == 'object')
...
Ja, aber die create-Funktion läuft nur ein einziges Mal, um das Wrapper-Element zu erstellen - die dürfte also deutlich zu vernachlässigen sein gegenüber allem, was in Schleifen abgearbeitet wird.
> Außerdem ist mir noch das cssText Attribute eingefallen, welches eigentlich in allen wichtigen Browsern, inkl. IE, funktioniert, damit könnte ich die Funktion nochmal deutlich beschleunigen
Auch hier - das wird vermutlich nur minimal was bringen.
Das, was in den Schleifen mit den ChildNodes von Elementen gemacht wird, das ist wenn die Baustelle, an der sich Optimierung wirklich lohnen könnte, sofern noch welche möglich.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.