| Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
treex:api-implementation [2015/12/14 11:18]
popel |
treex:api-implementation [2016/01/07 18:02]
popel |
| Metoda ''descendants'' tedy začne nejlevějším a iteruje až do nejpravějšího (a vynechá uzel, ze kterého to volám, pokud není ''add_self''). | Metoda ''descendants'' tedy začne nejlevějším a iteruje až do nejpravějšího (a vynechá uzel, ze kterého to volám, pokud není ''add_self''). |
| Problém je jen s neprojektivitami, takovéto uzly musím přeskočit. Každý uzel má tedy seznam (spoják) uzlů, v jejichž spanu (leftmost..rightmost) se slovosledně nachází a přitom není jejich potomkem. Většina uzlů je projektivních a má tedy tento seznam prázdný, takže při iteraci mám jen jeden if navíc. Zatím se mi tato implementace líbí nejvíc. | Problém je jen s neprojektivitami, takovéto uzly musím přeskočit. Každý uzel má tedy seznam (spoják) uzlů, v jejichž spanu (leftmost..rightmost) se slovosledně nachází a přitom není jejich potomkem. Většina uzlů je projektivních a má tedy tento seznam prázdný, takže při iteraci mám jen jeden if navíc. Zatím se mi tato implementace líbí nejvíc. |
| | |
| | Vylepšení1: |
| | Při zavolání z kořene stromu by se vrátil speciální iterátor, který vůbec nekontroluje seznamy neprojektivit (takže se ušetří to if, ale hlavně procházení všech seznamů). Toto vylepšení mi přijde zcela jasně přínosné. |
| | |
| | Vylepšení2: |
| | V seznamech neprojektivit budou uzly setříděné vzestupně dle hloubky. Jakmile narazím na uzel s vyšší hloubkou než uzel, který testuji (ze kterého jsou ''descendants'' zavolané), tak skončím a neprocházím zbytek seznamu. Zde si vůbec nejsem jist, zda to má cenu, protože sice ušetřím procházení části seznamu u některých uzlů, jenže zase přibude testování hloubky (kterou bych musel mít v tom seznamu asi předpočítanou, a tedy ji aktualizovat, když se změní). |
| |
| Alternativa: atribut _leftmost (a obdobně _rightmost) by se vyplňoval pouze tehdy, pokud by se sledováním nejlevějšího dítěte nedalo dostat do nejlevějšího potomka. Tedy v projektivních stromech by se ty atributy nemusely vyplňovat vůbec (vůbec by nezabíraly místo v hash-based objektech). Editace by pak mohly být o něco rychlejší, pokud detekuji, že projektivní strom měním na projektivní. Čtení ale bude pomalejší, protože budu muset iterovat do těch nejlevějších dětí (a ještě navíc testovat, zda není v uzlech vyplněn _leftmost). | Alternativa: atribut _leftmost (a obdobně _rightmost) by se vyplňoval pouze tehdy, pokud by se sledováním nejlevějšího dítěte nedalo dostat do nejlevějšího potomka. Tedy v projektivních stromech by se ty atributy nemusely vyplňovat vůbec (vůbec by nezabíraly místo v hash-based objektech). Editace by pak mohly být o něco rychlejší, pokud detekuji, že projektivní strom měním na projektivní. Čtení ale bude pomalejší, protože budu muset iterovat do těch nejlevějších dětí (a ještě navíc testovat, zda není v uzlech vyplněn _leftmost). |
| | |
| | |
| | ===== Benchmark načítání CoNLL-U vPerlu ===== |
| | Načítám cs-ud-train-l.conllu. |
| | |
| | 0.479s while (<$fh>) {chomp;} |
| | 1.409s + split /t/, ale hodnoty se zahodí a neukládají do proměnných |
| | 5.722s totéž, ale hodnoty atributů se uloží do proměnných (které se hned zahodí) |
| | 7.724s + uzly se vytvoří jako undef, uloží do pole @nodes, které se zahodí, vytváří se bundly |
| | 10.917s nedělá se split ani rehang, všechny atributy jsou prázdný řetězec, stromy ale mají uzly |
| | 13.460s korektní načtení, netestují se cykly, nevolá se set_parent (ale zopakuje se jeho kód) |
| | 15.903s korektní načtení, netestují se cykly, volá se set_parent($parent, {cycles=>'no-check'} ); |
| | 16.646s korektní načtení, testují se cykly |
| | 26.666s původní implementace načítání, kde se uzly vytvářejí pomocí $root->create_child a převěšují se pak z kořene na skutečného rodiče a děti jsou pole |
| | 19.029s totéž, ale bez převěšování, tedy vše visí na kořenu |
| | |
| | |
