Differences

This shows you the differences between two versions of the page.

--- treex:api-implementation [2015/12/11 12:29]
popel
+++ treex:api-implementation [2015/12/11 13:35]
ufal
@@ Line 43: / Line 43: @@
 Zde je vidět, že Devel::Size::total_size hlásí 96MB, ale ps hlásí 292MB.
 ==== Benchmark Perlích accessorů ====
-  Zápis následovaný čtením atributu
+Nejdřív jsem porovnal různé implementace a měřil kolikrát za sekundu se provede zápis následovaný čtením (stejného) atributu. H=hash-based object. A=array-based object. LV=lvalue (viz níže).
   LV V::Magic H         64 759/s
   LV V::Magic A         74 649/s
@@ Line 64: / Line 65: @@
   array              5 386 997/s
+Pak jsem vybral několik implementací a porovnával zápis a čtení zvlášť
   Zápis atributu
   H-lv-check-sentinel    714 566/s
@@ Line 101: / Line 103: @@
 Co z toho plyne?
-  * Všechny čtení i zápisy přístupy jsou zřejmě "dostatečně rychlé na Perl" (krom lvalue přes ''Variable::Magic'', ale to jsem hned po prvním experimentu zavrhl ve prospěch [[https://metacpan.org/pod/Sentinel|Sentinel]]).
+  * Všechny čtení i zápisy jsou zřejmě "dostatečně rychlé na Perl" (krom lvalue přes ''Variable::Magic'', ale to jsem hned po prvním experimentu zavrhl ve prospěch [[https://metacpan.org/pod/Sentinel|Sentinel]]).
   * 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 (''iset'' bude objekt držící všechny features).
   * Čtení je podobně rychlé jako zápis atributu obdobnou metodou.
@@ Line 116: / Line 118: @@
     * Přidáním kontroly/logování se lvalue zápis zpomalí sedminásobně, zatímco bez lvalue (tj. setter a getter) se zápis zpomalí jen dvojnásobně. Tedy použitím lvalue se zápis s kontrolou/logováním **zpomalí trojnásobně**. Samozřejmě pokud by ta kontrola/logování dělala něco složitějšího než kontrolu undefu, tak se asi rozdíl mezi lvalue accessorem a setterem ztratí.
     * To 3x zpomalení při zápisu by mi nevadilo. Ale to 5x násobné zpomalení při čtení je nepříjemné, protože čtení bývá mnohem častější než zápis.
+    * 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, že všechny atributy mají kontrolovaný/logovaný zápis, což snad nebude pravda). Odhaduji, že na parsing (plus tagging, nebo načtení z CoNLL-U) jedné věty (20 slov) potřebuji číst tak 1000 krát číst a 100 krát zapsat nějaký atribut, tedy s lvalue ztratím 200 **mikro**sekund. Přitom samotný parsing trvá aspoň několik **mili**sekund.
+==== Identifikátory ====
+V dosavadním Treexu byly identifikátory (uzlů) považovány za nevyhnutelnou režii a byly zpracovávány (generovány, indexovány) automaticky. Je otázka, jestli je to opravdu nutné za všech okolností, popř. jestli by to nešlo nějak zjednodušit, když víme, že valná část bloků identifikátory uzlů k ničemu nepotřebuje, navíc drtivá většina referencí je uzavřených uvnitř bundlu. Pokud se podaří sloučit a-stromy a t-stromy, velká část referencí odpadne, zbývající případy budou souviset asi hlavně s alignmentem a koreferencí.
+Nabízí se znovu zvážit:
+  - Jakých hodnot mají identifikátory nabývat
+  - Jak má být realizováno indexování identifikátorů
+) Hodnoty identifikátorů
+- atomické nebo strukturované (hierarchicky složením id dokumentu+bundlu+zóny+uzlu)?
+- pokud hierarchické, nedal by se přece jenom nějak využít ord? (jasně, pak by se muselo občas přepočítávat, otázka ale je, jak je v reálu vkládání uzlů časté)
+- v jakém scopu musí být id unikátní?
+) 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?

[ Back to the navigation ] [ Back to the content ]

Institute of Formal and Applied Linguistics Wiki

Differences