Hledání a nahrazování pomocí JavaScriptu

[Filip Jirsák]

A teraz by to chcelo zrovnat branky, bud by ste mal pouzit kod ktory ste sem postoval, alebo ja ten svoj optimalizujem.

Vy jste tvrdil, že je pomalé volat pro každé nahrazení funkci. To je kód, který je v tom testu. Já jsem v mém původním návrhu měl feturu navíc, že bylo možné každý token nahrazovat jinou náhradou, takže se tam volala další funkce. Nic takového váš kód nedělá, takže jsem srovnal podmínky tak, aby oba kódy dělaly to samé.

Naviac ked ten kod prebehne 1000000 krat tak jit s optimalizatorom bezpecne zafunguje. Preco by ale niekto ten isty text nahradzoval 1000000x dookola?

To jsou zase jen vaše dohady. Které se neukázaly jako moc dobré. Ak byste někdy dělal výkonnostní testy aplikace, věděl byste, že se kód často volá opakovaně, aby se výkon vůbec dal nějak změřit. Proč by někdo ten stejný text nahrazoval 1 000 000 × dokola byste měl odpovědět vy, protože vy jste přišel s tím, že je potřeba to optimalizovat na čas. Pokud se ten text bude nahrazovat jenom jednou a trvá to po jednu milisekundu, proč to optimalizovat?

Ale že jste to vy, dal jsem tam přesnější čítač času, takže teď už to můžete pustit i jenom jednou. Akorát že zjistíte, že to už se pohybujeme v oblasti chyby měření a jediné, co se dá říct, je to, že výkon těch funkcí je zhruba stejný. Což je opět v rozporu s vaší tvrzením, že můj kód je neefektivní.

Njn, ako som si myslel.

Njn, jenže to už testujete něco jiného, protože jste kus vaší funkce vytrhl mimo test, takže neměříte dobu trvání celé vaší funkce. Pak je to opravdu optimalizace na velký počet nahrazování se stejnou sadou tokenů (což je zase váš nevyslovený předpoklad, že něco takového bude potřeba), tedy je to jiné zadání. Jinak v tomhle speciálním případu (o kterém ale původně nebyla řeč) je vaše funkce opravdu cca o 1/3 rychlejší. Láme se to teprve u dost vysokého počtu tokenů – u deseti tisíc tokenů už je výrazně efektivnější hledání tokenů v hashmapě než jejich procházení po jednom v regulárním výrazu.

Ale to je len tym ze sa ten kod zopakuje milion krat a tym ste si zarucil ze sa to zkompiluje.

To vaše vytváření regulárního výrazu se zaručeně nezkompiluje ani při milionu provedení?

[Reklama]

[Death Walker]

A teraz by to chcelo zrovnat branky, bud by ste mal pouzit kod ktory ste sem postoval, alebo ja ten svoj optimalizujem.

Vy jste tvrdil, že je pomalé volat pro každé nahrazení funkci. To je kód, který je v tom testu. Já jsem v mém původním návrhu měl feturu navíc, že bylo možné každý token nahrazovat jinou náhradou, takže se tam volala další funkce. Nic takového váš kód nedělá, takže jsem srovnal podmínky tak, aby oba kódy dělaly to samé.

Njn, ako som si myslel.

Njn, jenže to už testujete něco jiného, protože jste kus vaší funkce vytrhl mimo test, takže neměříte dobu trvání celé vaší funkce. Pak je to opravdu optimalizace na velký počet nahrazování se stejnou sadou tokenů (což je zase váš nevyslovený předpoklad, že něco takového bude potřeba), tedy je to jiné zadání. Jinak v tomhle speciálním případu (o kterém ale původně nebyla řeč) je vaše funkce opravdu cca o 1/3 rychlejší. Láme se to teprve u dost vysokého počtu tokenů – u deseti tisíc tokenů už je výrazně efektivnější hledání tokenů v hashmapě než jejich procházení po jednom v regulárním výrazu.

Takze vy si svoj kodoptimalizujete ale pritom trvate aby ten moj ostal v povodnej podobe. Ste tak ferovy Nehrajte marias ani ine podobne hry, mohlo by to byt bolestive.

Naviac ked ten kod prebehne 1000000 krat tak jit s optimalizatorom bezpecne zafunguje. Preco by ale niekto ten isty text nahradzoval 1000000x dookola?

To jsou zase jen vaše dohady. Které se neukázaly jako moc dobré. Ak byste někdy dělal výkonnostní testy aplikace, věděl byste, že se kód často volá opakovaně, aby se výkon vůbec dal nějak změřit. Proč by někdo ten stejný text nahrazoval 1 000 000 × dokola byste měl odpovědět vy, protože vy jste přišel s tím, že je potřeba to optimalizovat na čas. Pokud se ten text bude nahrazovat jenom jednou a trvá to po jednu milisekundu, proč to optimalizovat?

Ale že jste to vy, dal jsem tam přesnější čítač času, takže teď už to můžete pustit i jenom jednou. Akorát že zjistíte, že to už se pohybujeme v oblasti chyby měření a jediné, co se dá říct, je to, že výkon těch funkcí je zhruba stejný. Což je opět v rozporu s vaší tvrzením, že můj kód je neefektivní.

Pozrite si ako JIT v javascripte funguje. Pri neopakovani kodu takmer vzdy pobezi interpret. JIT zafunguje az po niekolkych opakovaniach.

Ale to je len tym ze sa ten kod zopakuje milion krat a tym ste si zarucil ze sa to zkompiluje.

To vaše vytváření regulárního výrazu se zaručeně nezkompiluje ani při milionu provedení?

Mno, to RE engine je uz skompilovane, vsak. Rovnako sa skompiluje aj ten regular, ci uz pomocou re.compile alebo volanimtoho isteho s konstruktoru. Je skompilovane vzdy a nie len v urcitych pripadoch.

[Filip Jirsák]

Takze vy si svoj kodoptimalizujete ale pritom trvate aby ten moj ostal v povodnej podobe. Ste tak ferovy Nehrajte marias ani ine podobne hry, mohlo by to byt bolestive.

Já jsem pouze kód upravil tak, aby obě dvě verze dělaly funkčně to samé. Ano, když chci porovnat dva přístupy k řešení téhož problému, připadá mi férové, když obě varianty řeší tentýž problém a ne když jedna varianta toho umí mnohem víc, co není k řešení problému potřeba.

Vy si svůj kód klidně optimalizujte, nikde jsem nepsal, že to dělat nesmíte. Akorát by to měla být optimalizace řešení problému a ne optimalizace pro konkrétní test. taky bych uměl „optimalizovat“ kód tak, že si rovnou uložím výstupní text k příslušnému testu do proměnné a nebudu volat žádnou funkci.

Pozrite si ako JIT v javascripte funguje.

Že máte po tom fiasku pořád odvahu někoho poučovat…

Mno, to RE engine je uz skompilovane, vsak. Rovnako sa skompiluje aj ten regular, ci uz pomocou re.compile alebo volanimtoho isteho s konstruktoru. Je skompilovane vzdy a nie len v urcitych pripadoch.

Ono není skompilovat jako skompilovat. Můžete kompilovat do nativního kódu, do optimalizovaného nativního kódu, do AST, do bajtkódu…