Je hledání sourozence v DOMu rychlejší než hledání podle ID?

Igor:
Tomu spanu pridaj nejake id povedzme ulozit cize <span id="ulozit">Uložit</span>
Kvoli lepsiemu vykonu mozes dat aj textaree id-cko povedzme id="text"

Reaguji na pcmanika:
„resp. tomu spanu pridaj nejake id“
Proč je id lepší než onclick? Anonymní handler na pojmenovaném elementu je lepší než anonymní handler na anonymním elementu?

„Kvoli lepsiemu vykonu mozes dat aj textaree id-cko“
Jak to zlepší výkon? Nalezení předchozího potomka je pomalejší než nalezení elementu podle ID? Proč by mělo být?

Chamurappi:
„Proč je id lepší než onclick? Anonymní handler na pojmenovaném elementu je lepší než anonymní handler na anonymním elementu?“
Je dobre oddelovat javascript od zbytku html, a drzat si ho samostatne, pridava to na prehladnosti a ulahcuje buduce zmeny, preto.

„Jak to zlepší výkon? Nalezení předchozího potomka je pomalejší než nalezení elementu podle ID? Proč by mělo být?“
Pomocou selectoru id, je to rychlejsie ako prechadzat cez strukturu dokumentu.

Reaguji na pcmanika:
„Je dobre oddelovat javascript od zbytku html“
Zpravidla ano, ale u takovýchto jednorázovek to nemá cenu. Nevidím to tak černobíle.
Ídéčka i třídy působí v rámci dokumentu podobně jako v libovolném objektově orientovaném jazyce proměnná v globálním kontextu — musím si dávat pozor, co a jak nazývám, abych si později nevyrobil konflikt. Můžu mít jen jedno id="ulozit" a i kdybych místo id použil class, musel bych si pamatovat, že se jí mám vyhýbat, protože tahle class už má globálně daný účel (v rámci všech stránek, kde je přilinkovaný skript). To je v důsledku docela velká daň za to, že bude HTML kód hezky vypadat. Zatím jsem viděl jen málo projektů, které měly v ídéčkách či třídách jasný systém (např. podobný stromové hierarchii) — většinou je to jeden velký guláš. Idea, že by JavaScript měl být nevtíravý (unobtrusive), je sice pěkná, ale měla by být prostředkem k omezení rizika konfliktu, nikoliv potenciálním původcem.

„Pomocou selectoru id, je to rychlejsie ako prechadzat cez strukturu dokumentu.“
Funkce .prev prochází postupně previousSiblingy a zastaví se, jakmile narazí na jakýkoliv element. Můžeš něčím doložit, že je takový postup pomalejší než hledání podle id? Neprováděl jsem žádné testy, ale připadá mi to nepravděpodobné.

Chamurappi:
„Neprováděl jsem žádné testy, ale připadá mi to nepravděpodobné.“
Spravil som maly test, popripade druhy test, dufam ze som tam nezaviedol ziadne nepresnosti, posud sam a uvidis ze id je rychlejsie

Porovnáváš něco jiného. Chamurappi psal o použití this.

Reaguji na pcmanika:
První test zkoumá, jestli je rychlejší zaměření podle ID, nebo zaměření podle ID + následné zaměření souseda. Netestuje, jestli je rychlejší zaměření podle ID, nebo zaměření souseda. Druhý test zkoumá vesměs totéž, co první test, akorát má na druhou část navěšené závaží v podobě množiny všech <span>ů. Zohledníme-li, co testuješ, tak výsledky naznačují, že hledání podle ID není rychlejší.

Chamurappi:
Neviem ako reprodukovat this v tych testoch, mas nejake navrhy? Lebo by ma skutocne zaujimalo, co je rychlejsie.

Chamurappi:
Upravena verzia uz podla mojho nazoru odzrkadluje skutocnost, nakolko odkaz na element je v premennej, teda sa jedna o najblizsie mozne priblizenie k this, a vysledky stale hraju do karat selectovaniu pomocou id http://jsperf.com/id-prev/2

pcmanik:
Ano - i ne-jQuery jednoduchý kód potvrzuje (test proveden i mimo jsPerf), že traverzování z this je ve skutečnosti pomalejší, pokud musíme testovat nodeType sourozenců (kupříkladu kvůli prázdným textovým uzlům) - a to i v případě, že se jedná o přímé sourozence bez dalších zpomalujících neelementových meziuzlů. Jednoduché sáhnutí na samotné this.previousSibling je pak rychlejší než vyhledávání podle ID, nicméně co obsahuje lze u parsovaného HTML kódu - ne u dynamicky generované struktury DOM - stěží určit.

Reaguji na pcmanika:
„vysledky stale hraju do karat selectovaniu pomocou id“
Mno jo, vypadá to tak. Háček je skutečně v tom testování nodeType (uvnitř jQuery), hledání podle ID je tak pekelně rychlé, že mu i primitivní kontrola vlastnosti v konkurenčním postupu zajistí vítězství :-)
Mimochodem, ve tvém i Witikově testu dostávám s Explorerem 7 opačný výsledek.

Tak či tak rozsévat ídéčka jen kvůli ušetření pár mikrosekund bych z již výše zmíněného důvodu v tomto případě nedoporučoval. Pokud tvoří <textarea> se <span>em nerozlučnou dvojici a působí v rámci stránky jako jednotný celek (přenositelný případně jinam), zůstal bych u jednoho ID.


Reaguji na Witika:
„Jednoduché sáhnutí na samotné this.previousSibling je pak rychlejší než vyhledávání podle ID“
Dle očekávání. Tipnul bych si, že (dosud nepříliš podporovaný) previousElementSibling bude též rychlejší než hledání dle ID.

„nicméně co obsahuje lze u parsovaného HTML kódu - ne u dynamicky generované struktury DOM - stěží určit“
Proč? Pokud není mezi zápisy elementů v kódu mezera, obsahuje previousSibling vždy element. Spolehlivě, ve všech prohlížečích.

Vím, že část programátorů říkává „mezera sem, mezera tam, na to v HTML nejde spoléhat“, ale nevím, odkud tuto laxnost berou. V HTML a XML jsou určitá pravidla pro normalizaci bílých znaků a ta říkají, že mezi pěti mezerami a jednou mezerou sice rozdíl není, ale mezi mezerou a nemezerou už je. Přeci když zvýrazním písmenko uvnitř slova, je jasné, že nechci kolem elementu mezery, proto nejsou ani ve zdrojáku, a naopak když zvýrazním celé slovo, nechci ho slít dohromady s předchozím slovem. Zrovna tak můžu chtít mít kód napsaný tak, jak ho napsal Igor v [#1] — bez mezery — pak stačí this.previousSibling.value a kdo mi mezi značky přidá mezeru, tím nakrmím krokodýla.

Chamurappi:
„Proč? Pokud není mezi zápisy elementů v kódu mezera, obsahuje previousSibling vždy element. Spolehlivě, ve všech prohlížečích.“
S tím souhlasím, ale obvykle rád při psaní html kódu odsazuji elementy podle hloubky jejich začlenění, tzn.:

Nejspíš bych mohl před nahráním na web vše zhustit dohromady, ale pokud tak neučiním, tak je testování podle NodeType potřeba, nebo v případě podpory <code>previousElementSibling</code>. Sice nevím jestli je to součástí určité úrovně DOM, ale podpora je zatím poměrně mizerná. Obecná funkce by poté mohla vypadat nějak takto:

Ještě mě napadlo, že tahle debata (a i zvolený název tématu) se začala stáčet podle mě mírně zavádějícím směrem. Rozdíl v rychlosti samotného vyhledávání je totiž (pokud nehledáme desítky tisíc elementů) skutečně neznatelný a jsou i jiná kritéria dobře napsaného kódu jako čitelnost, udržovatelnost, logičnost a neopakování svého zápisu. Tzn. neuvaloval bych rozhodnutí co je lepší / horší pouze na základě toho, co je rychlejší. Bavíme se přeci jenom o scriptovacím jazyku - základní ideou zde je rychlost a flexibilita vývoje nad rychlostí překladu.

Můžme mít různé názory na přehlednost a opravitelnost kódu. Také však jsou rozdíly v množství. Psal jsem PHP/JS skripty pro vytěžování databází o tisícovkách položek, přičemž si klient přál zobrazení všech nalezených najednou. Generování nezávislých řad id-ček je v takovém případě prakticky nemožné a, protože kód stejně generuje PHP a musí se v něm vyznat především interpretr HTML, dal jsem přednost přidělení id-čka jen pro těžko popsatelnou skupinu elementů, ale uvnitř skupiny s pevnou strukturou už jsem traversoval pouze pomocí relativních odkazů.

V poslední, zatím připravované versi, jsem přešel na generování celé tabulky přímo JavaScriptem, pro který PHP pouze dodá seznam položek, vyždímaných z databáze. V takovém kódu se už moc HTML nenajde a přehlednost se postěhovala někam úplně jinam. :-) Přenášených dat je podstatně méně a při klientských operacích nad stejnými daty (například skrytí nějakého sloupce tabulky) se dosahuje viditelně rychleší odezvy, než když by se znovu generovala clelá stránka pomocí PHP.

sysel:
„dal jsem přednost přidělení id-čka jen pro těžko popsatelnou skupinu elementů“
Samozřejmě nevím přesně o co se jednalo, ale dovedu si představit, že libovolně složitou strukturu lze rozdělit na jednotlivé oddíly (reprezentované v kódu blokovými elementy / případně dokument fragmenty při generaci javascriptem) a přes ty pak iterovat. Tzn. za předpokladu, že je možné vygenerovaná data popsat jako soubor oddílů obsahujících shodnou strukturu, nemělo by být použití id ani nutné, maximálně pro svrchní obalovací wrapper element.

Reaguji na Igora:
Samozřejmě, že nebyl. Hledání čehokoliv je pomalejší než žádné hledání. Hledání podle ID a podle názvu elementu také bude pomalejší než hledání podle ID.

„taky pomalejší“
Hledání sourozence by bylo rychlejší než hledání podle ID, kdyby ho nebrzdila kontrola v jQuery. Veškeré tyhle časové rozdíly jsou zanedbatelné ve srovnání s tím, kolik času spolkne samotný framework.
Mimochodem, kolik účtů si tu ještě založíš?


Reaguji na Witika:
„Obecná funkce by poté mohla vypadat nějak takto“
Nebo by se v závislosti na podpoře previousElementSibling mohla přiřazovat do prev různě stavěná funkce.

„Nejspíš bych mohl před nahráním na web vše zhustit dohromady“
To také nemusí být správné. Kde jsou mezery, má být mezera, kde nejsou mezery, nemá být mezera :-)

Chamurappi:
„mohla přiřazovat do prev různě stavěná funkce“
Z hlediska výkonu asi nejčistší řešení.