Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
treex:api-implementation [2015/12/11 11:12] popel |
treex:api-implementation [2015/12/11 13:34] ufal |
||
---|---|---|---|
Line 28: | Line 28: | ||
Reference v Perlu zabírá stejně jako int (a to těch 24 bajtů samostatně, | Reference v Perlu zabírá stejně jako int (a to těch 24 bajtů samostatně, | ||
- | (V céčku na 64bitech má typicky pointer 8 bajtů, int 4 bajty a long long int 8 bajtů, | + | (V Céčku na 64bitech má typicky pointer 8 bajtů, int 4 bajty a long long int 8 bajtů, v poli to zůstává stejné, v hashi přibude režie dle míry naplnění tabulky, ale v Céčku se objekty nedávají do hashe, leda snad wild atributy.) |
Z hlediska rychlosti by bylo lepší ukládat přímo referenci na string (místo intu, kterým by se pak muselo indexovat pole). | Z hlediska rychlosti by bylo lepší ukládat přímo referenci na string (místo intu, kterým by se pak muselo indexovat pole). | ||
Ušetřil bych 32 bajtů na každém stringovém atributu (a pokud by měl ten string víc než 15 znaků, tak ještě víc) a navíc bych potřeboval paměť pro slovník, která je ale (díky zipfovskému rozdělení lemmat, na větších dokumentech) zanedbatelná. | Ušetřil bych 32 bajtů na každém stringovém atributu (a pokud by měl ten string víc než 15 znaků, tak ještě víc) a navíc bych potřeboval paměť pro slovník, která je ale (díky zipfovskému rozdělení lemmat, na větších dokumentech) zanedbatelná. | ||
Line 43: | Line 43: | ||
Zde je vidět, že Devel:: | Zde je vidět, že Devel:: | ||
+ | |||
+ | ==== Identifikátory ==== | ||
+ | |||
+ | V dosavadním Treexu byly identifikátory (uzlů) považovány za nevyhnutelnou režii a byly zpracovávány (generovány, | ||
+ | |||
+ | Nabízí se znovu zvážit: | ||
+ | - Jakých hodnot mají identifikátory nabývat | ||
+ | - Jak má být realizováno indexování identifikátorů | ||
+ | |||
+ | 1) Hodnoty identifikátorů | ||
+ | - atomické nebo strukturované (hierarchicky složením id dokumentu+bundlu+zóny+uzlu)? | ||
+ | - pokud hierarchické, | ||
+ | - v jakém scopu musí být id unikátní? | ||
+ | |||
+ | 2) Indexování identifikátorů | ||
+ | - zanášet do indexu automaticky jako nyní, nebo líně (při prvním využití), nebo ještě nějak jinak? | ||
+ | - kde držet index (asi nadále mapu id-uzel)? U dokumentu jako teď, nebo u runneru? | ||
+ | |||
==== Benchmark Perlích accessorů ==== | ==== Benchmark Perlích accessorů ==== | ||
- | Zápis i čtení | + | Nejdřív jsem porovnal různé implementace a měřil kolikrát za sekundu se provede zápis následovaný |
- | LV V::Magic H 64759/s | + | LV V::Magic H 64 759/s |
- | LV V::Magic A 74649/s | + | LV V::Magic A 74 649/s |
- | LV Sentinel H 169605/s | + | LV Sentinel H 169 605/s |
- | LV Sentinel A 170267/s | + | LV Sentinel A 170 267/s |
- | Moose | + | Moose |
- | object H 1193837/s | + | object H 1 193 837/s |
- | object A 1233004/s | + | object A 1 233 004/s |
- | LV C:: | + | LV C:: |
- | Mouse | + | Mouse |
- | LV C:: | + | LV C:: |
- | C:: | + | C:: |
- | Moops | + | Moops |
- | Moo | + | Moo |
- | O:: | + | O:: |
- | C:: | + | C:: |
- | hash 4969215/s | + | hash 4 969 215/s |
- | array | + | array |
+ | Pak jsem vybral několik implementací a porovnával zápis a čtení zvlášť | ||
Zápis atributu | Zápis atributu | ||
H-lv-check-sentinel | H-lv-check-sentinel | ||
Line 83: | Line 102: | ||
A-direct | A-direct | ||
- | Čtení atributu: | + | Čtení atributu: |
- | h-get_lemma_perl | + | h-lv_check_sentinel |
- | a-get_lemma_perl | + | a-lv_check_sentinel |
- | h-lv_lemma_perl | + | --- |
- | a-lv_lemma_perl | + | h-get_lemma_perl |
+ | a-get_lemma_perl | ||
+ | h-lv_lemma_perl | ||
+ | a-lv_lemma_perl | ||
--- | --- | ||
- | h-lv_lemma_xs | + | h-lv_lemma_xs |
- | a-lv_lemma_xs | + | a-lv_lemma_xs |
- | h-get_lemma_xs | + | h-get_lemma_xs |
- | a-get_lemma_xs | + | a-get_lemma_xs |
--- | --- | ||
- | h-direct | + | h-direct |
- | a-direct | + | a-direct |
+ | Co z toho plyne? | ||
+ | * Všechny čtení i zápisy jsou zřejmě " | ||
+ | * Pole jsou jen o málo rychlejší než hashe. Možná by se rozdíl zvětšil, kdybych měl v objektu více atributů než jeden, ale víc než 16 jich asi mít nechceme ('' | ||
+ | * Čtení je podobně rychlé jako zápis atributu obdobnou metodou. | ||
+ | * Nejrychlejší je přímý přístup do hashe/pole (tedy '' | ||
+ | * XS implementace jsou asi dvakrát rychlejší než perlové (a to v těch perlových dělám, '' | ||
+ | * Největší otázka z hlediska API je, zda povolit **lvalue accessory**, | ||
+ | * Obzvlášť užitečné je použití typu '' | ||
+ | * V Perlu to není moc zvykem (byť to byla jedna z hlavních motivací uživatelských lvalue funkcí). | ||
+ | * Dokud při zápisu nechci dělat nic jiného (kontroly, logování, | ||
+ | * Jakmile chci nějakou kontrolu v setteru (třeba že ord je kladný integer nebo deprel je jen z těch povolených), | ||
+ | * Pokud chci dělat kontroly (či logování atd.) u lvalue accessoru, musím použít (něco jako) [[https:// | ||
+ | * Hlavní problém vidím v tom, že se mi pak zpomaluje i čtení atributu, při jehož zápisu je lvalue-check. Celé to dělám proto, aby se to " | ||
+ | * Když bych tedy v Perlu používal lvalue accessory, tak jakmile se rozhodnu přidat nějakou kontrolu/ | ||
+ | * Přidáním kontroly/ | ||
+ | * To 3x zpomalení při zápisu by mi nevadilo. Ale to 5x násobné zpomalení při čtení je nepříjemné, | ||
+ | * Na druhou stranu je otázka, zda se podaří zrychlit zbytek Treexu natolik, aby se projevil rozdíl v řádu 200 **nano**sekund na čtení jednoho atributu (pesimisticky předpokládejme, |