[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki

[ Back to the navigation ]

You are here: start » treex » api-implementation

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
treex:api-implementation [2015/12/11 12:29]
popel 		treex:api-implementation [2015/12/11 12:51]
popel
Line 45: Line 45:
  
 ==== Benchmark Perlích accessorů ==== ==== 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 H         64 759/s 
   LV V::Magic A         74 649/s    LV V::Magic A         74 649/s 
Line 64: Line 64:
   array              5 386 997/s    array              5 386 997/s 
  
 +Pak jsem vybral několik implementací a porovnával zápis a čtení zvlášť
   Zápis atributu   Zápis atributu
   H-lv-check-sentinel    714 566/s   H-lv-check-sentinel    714 566/s
Line 101: Line 102:
  
 Co z toho plyne? 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).   * 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.   * Čtení je podobně rychlé jako zápis atributu obdobnou metodou.
Line 116: Line 117:
     * 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í.     * 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.     * 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.

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