[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki

• ÚFAL Wiki Home
• ÚFAL Home
• Sitemap
• RSS
• ÚFAL calendar
• Recent changes
• Login
• Hledat:

[ Back to the navigation ]

Differences

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

View differences: Side by SideInline Go

Link to this comparison view

Both sides previous revision Previous revision 2016/01/08 23:17 popel 2016/01/08 19:27 popel 2016/01/08 19:03 popel 2016/01/08 18:28 popel 2016/01/08 17:29 popel 2016/01/08 14:48 popel 2016/01/08 00:09 popel 2016/01/07 18:02 popel 2015/12/15 16:25 popel 2015/12/14 11:18 popel 2015/12/14 03:43 popel 2015/12/14 01:26 popel 2015/12/11 13:35 ufal 2015/12/11 13:34 ufal 2015/12/11 12:51 popel 2015/12/11 12:29 popel 2015/12/11 11:16 popel 2015/12/11 11:14 popel 2015/12/11 11:12 popel 2015/12/11 11:09 popel 2015/12/11 11:06 popel 2015/12/11 10:31 popel 2015/12/11 10:13 popel 2015/12/10 18:41 popel 2015/12/09 15:04 popel 2015/12/08 21:32 popel 2015/12/08 21:31 popel 2015/12/08 17:52 popel created Go		2016/01/08 23:17 popel 2016/01/08 19:27 popel 2016/01/08 19:03 popel 2016/01/08 18:28 popel 2016/01/08 17:29 popel 2016/01/08 14:48 popel 2016/01/08 00:09 popel 2016/01/07 18:02 popel 2015/12/15 16:25 popel 2015/12/14 11:18 popel 2015/12/14 03:43 popel 2015/12/14 01:26 popel 2015/12/11 13:35 ufal 2015/12/11 13:34 ufal 2015/12/11 12:51 popel 2015/12/11 12:29 popel 2015/12/11 11:16 popel 2015/12/11 11:14 popel 2015/12/11 11:12 popel 2015/12/11 11:09 popel 2015/12/11 11:06 popel 2015/12/11 10:31 popel 2015/12/11 10:13 popel 2015/12/10 18:41 popel 2015/12/09 15:04 popel 2015/12/08 21:32 popel 2015/12/08 21:31 popel 2015/12/08 17:52 popel created Go Next revision Both sides next revision
treex:api-implementation [2015/12/11 13:34] ufal		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.		Zde je vidět, že Devel::Size::total_size hlásí 96MB, ale ps hlásí 292MB.
-
-	==== 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ů
-
-	1) 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í?
-
-	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?
Line 136:		Line 119:
	* 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.		* 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ů
		+
		+	1) 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í?
		+
		+	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?
		+
		+
		+

---

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