[JS] Traagheid opbouw LI's

[dominic]

Na de search te hebben gebruikt bleef ik toch nog met een onbevredigd gevoel zitten, wegens geen bruikbare resultaten

Mijn vraag:

In javascript bouw ik in mijn HTML pagina (Die onder IE getoond wordt) en UL/LI boom op. (Systeemobjecten van sql: Tabellen en kolommen als tree weergeven maar dat doet er nu even niet toe).

code:

function buildTree(oParent, oXmlNodes)
{
  var oUL = document.createElement("UL");
  oParent.appendChild(oUL);

  for (i=0;i<oXmlNodes.childnodes.length;i++)
  {
     var oLI = document.createElement("LI");
     oUL.appendChild(oLI);
     
     oLI.innerText = oXmlNodes.childnodes(i).getAttribute("name");

     if (oXmlNodes.childnodes(i).childnodes.length > 0)
         buildTree(oLI, oXmlNodes.childnodes(i));
  }
}

Een klein voorbeeld _{(even uit het hoofdje trouwens dus hij kan incorrect zijn)} van de recursieve functie die ik gebruik om de UL/LI tree op te bouwen, dit werkt overigens prima.

Waar het mij om gaat is de snelheid waarmee dit gebeurt. Als ik in plaats van een UL/LI structuur bijvoorbeeld een SPAN structuur gebruik dan is dit 100x zo snel, maar de UL/LI structuur is gewoon baggertraag..

Dit schijnt dus een bug te zijn in het gedeelte waar de LI's worden toegevoegd aan de UL, het schijnt dat het object steeds opnieuw gerenderd wordt wanneer een LI toegevoegd wordt. Ik heb gehoord dat er een ongedocumenteerde attribute van een UL of LI voor IE is die dit proces aanzienlijk zou moeten versnellen..

Wie weet deze attribute?

[ Voor 5% gewijzigd door dominic op 27-03-2003 13:52 ]

[Bosmonster]

Een stuk sneller dan dit dynamische gedoe is altijd gewoon de html genereren en die vervolgens in een keer in je document te plaatsen. Deze methode is niet zo netjes, maar meestal vele malen sneller.

Kleinigheidje in for-loops trouwens: Gebruik altijd var i=0, anders gebruikt ie een globale variabele i.

[ Voor 22% gewijzigd door Bosmonster op 27-03-2003 14:14 ]

[dominic]

Bosmonster schreef op 27 maart 2003 @ 14:13:
Een stuk sneller dan dit dynamische gedoe is altijd gewoon de html genereren en die vervolgens in een keer in je document te plaatsen. Deze methode is niet zo netjes, maar meestal vele malen sneller.

Dit kan ik helaas niet doen, omdat ik ook nog custom event functions en andere zaken aan de LI's heb hangen. (Die werken helaas niet altijd als ik ze als "string" toevoeg..)

[ Voor 13% gewijzigd door dominic op 27-03-2003 14:15 ]

[dominic]

Ok, ik ben er inmiddels achter dat de volgende methode ietsje sneller is maar nog niet optimaal.

code:

var tUL = document.createElement("UL");
var tLI = document.createElement("LI");

function buildTree(oParent, oXmlNodes)
{
  var oUL = oParent.appendChild(tUL.cloneNode(true));
  
  for (i=0;i<oXmlNodes.childnodes.length;i++)
  {
     var oLI = oUL.appendChild(tLI.cloneNode(true));
          
     oLI.innerText = oXmlNodes.childnodes(i).getAttribute("name");

     if (oXmlNodes.childnodes(i).childnodes.length > 0)
         buildTree(oLI, oXmlNodes.childnodes(i));
  }
}

Maarja, nog niet optimaal dus, deze code is sneller maar de feitelijke bug is nog niet verholpen..

[Verwijderd]

het verbaast me dat het uberhaupt goedgaat omdat je for(i=0 gebruikt i.p.v. for(var i=0 ...iets dat bij recursie toch wel belangrijk is.

Waarom het zo traag gaat zou ik niet durven zeggen. Ik zie zo gauw niets wat de boel op zou kunnen houden. Dit zou nog een kleine verbetering kunnen opleveren

JavaScript:

var tUL = document.createElement("UL");
var tLI = document.createElement("LI");

function buildTree(oParent, oXmlNodes) {
    var oUL = oParent.appendChild(tUL.cloneNode(true));

    var iLength = oXmlNodes.childnodes.length;
    for (var i=0;i<iLength;i++) {
        var oLI = oUL.appendChild(tLI.cloneNode(true));
        
        var aChildNodes = oXmlNodes.childnodes(i);
        oLI.innerText = aChildNodes.getAttribute("name");
        
        if (aChildNodes.childnodes.length > 0)
            buildTree(oLI, aChildNodes);
    }
}

[ Voor 4% gewijzigd door Verwijderd op 27-03-2003 18:06 . Reden: die 'var' he :P ]

[dominic]

Verwijderd schreef op 27 March 2003 @ 18:05:
het verbaast me dat het uberhaupt goedgaat omdat je for(i=0 gebruikt i.p.v. for(var i=0 ...iets dat bij recursie toch wel belangrijk is.

[..]

In m'n openingspost stond al dat ik het uit m'n hoofdje uittikte hier.. Er konden dus fouten in zitten.. Ik declareer mijn variabelen trouwens meestal van te voren (i,n,k, dat soort dingen, die gebruik je toch overal)

[ Voor 65% gewijzigd door dominic op 27-03-2003 20:41 ]

[dominic]

Even een kick.. Misschien iemand die nog wat weet?

[dominic]

Laatste kick, en dan laat ik het topic zinken tot in de oneindige diepten van de GoT-archieven..

[Bosmonster]

Nog steeds de eerste opmerking Events e.d. kunnen geen probleem opleveren daarbij. Als je bijvoorbeeld aan je gegenereerde LI's classes of ID's meegeeft, kun je deze vervolgens in een loop je voorzien van de nodige events bijvoorbeeld.

[Verwijderd]

Je zou kunnen proberen om geneste DIV-jes met rechtermarge te gebruiken. Als er idd een UL/LI render bug is, zou je er dan geen last meer van hebben. Maar ja, niet echt netjes.

En verder, de DOM-API is voornamelijk handig als je incidenteel random access in de boom nodig hebt. Kun je je dingetje niet beter doen met een transformatie of zo (ik heb even niet helemaal door wat je progje doet ).

[dominic]

Verwijderd schreef op 14 April 2003 @ 21:52:
Je zou kunnen proberen om geneste DIV-jes met rechtermarge te gebruiken. Als er idd een UL/LI render bug is, zou je er dan geen last meer van hebben. Maar ja, niet echt netjes.

En verder, de DOM-API is voornamelijk handig als je incidenteel random access in de boom nodig hebt. Kun je je dingetje niet beter doen met een transformatie of zo (ik heb even niet helemaal door wat je progje doet ).

Het geeft tabellen en views weer uit een willekeurige dbase in een UL/LI structuur.. Hij kan helaas niet in een transform omdat de structuur clientsided te verversen moet zijn (Bijvoorbeeld bij het kiezen van een andere dbase, via XMLHTTP wordt de data dan netjes in jscript binnengehaald).

[Verwijderd]

Grappig, met zoiets ben ik ook bezig. Ik doe dat ook "single-paged". Hoe ik dat doe: ik vraag aan SQL Server een lijst van tabellen, die krijg ik terug in XML als een stream, die ik naar de client pomp.

Die doet op z'n beurt een transformatie in javascript met een XSLT. Dit resulteert in een stukje HTML dat de nieuwe SELECT voorstelt. Dan vervang ik de .outerHTML property van de oude SELECT door het nieuwe, en voila, een nieuwe lijst