57 odpovědí na toto téma

[taxoft]

A taky pro každou Kes hledáš waypointy a listingy, vyrábís počítaná pole a hromady dalších operaci, které tam jsou potřeba? Nějaký výkon taky padne na oběť objektových střev, což se už několikrát hodně hodilo zachránilo to mě duševní zdraví. Taky záleží na filtrech, co používáš. Některé potřebuji nemalý strojový čas.
Občas se mi i tam daří nějaká menší optimalizace. Ale že bych teď vytáhl špunt, a ono to běželo dvakrát rychleji, to nemohu sloužit.

Filtry = 0. Waypointy nepotřebuji. Počítaná pole nepotřebuji. Jen zobrazit seznam podle listu. Proto by to asi musela být jiná funkce: Quick Open List nebo tak něco. Select * from geocache where gccode in (opened_list).

[nalano]

Mi trvá načtení listu 45s. Mám tam v zafiltrovaném listu cca 110000keší, Filtr s vynechanými eventy, bez archivovaných. Celkem má databáze 1,4 GB. Je to na asi 5 let starém notebooku, ale s SSD.

Jak máš velkou DB? Nemáš tam řazení keší podle nějakého neindexovaného sloupce? Třeba dle FP seřadit trvá neskutečně dlouho.

[Arne1]

Tak všechny polygony, které prošly mýma rukama, jsem upravil na UTF. V souvislosti s tím, jsem zvednul hlavní číslo verze. Závislost na GG jsem u některých už posunul na 2.10.6, u některých zůstala původní.

Nedělal jsem Česko, do toho nechci Gordovi zasahovat.

[gord]

Gordovi? Nepamatuju se, ze bych nekdy delal polygony. Pokud jde o me, klidne je udelej taky. Priprada mi docela rozumne, pokud si jednu cast geogetu vezme na starost celou nekdo jiny nez Haluma. Ty mas v polygonech spoustu prace a mas na to bat, jak jsi psal a jsi ochotny se tomu venovat. Tak proc ne.

[HaLuMa]

Ceske polygony jsem kdysi delal ja. Jen cas na upravu nejak zrovna nemam, a ony by klidne taky chtely zaktualizovat...

[taxoft]

Mi trvá načtení listu 45s. Mám tam v zafiltrovaném listu cca 110000keší, Filtr s vynechanými eventy, bez archivovaných. Celkem má databáze 1,4 GB. Je to na asi 5 let starém notebooku, ale s SSD.

Jak máš velkou DB? Nemáš tam řazení keší podle nějakého neindexovaného sloupce? Třeba dle FP seřadit trvá neskutečně dlouho.

Řazení mám podle kódu. Žádný filtr. Zkusím omezit sloupce, zatím pracuji vždy se stejnou množinou, ale pro účel, pro který načítám ten velký list, všechny nepotřebuji.

Dělám to nad částí DB - necelé 4 GB soubor.

[Arne1]

Ceske polygony jsem kdysi delal ja. Jen cas na upravu nejak zrovna nemam, a ony by klidne taky chtely zaktualizovat...

Sorry, není tam napsanej Gord ale Geby (holt "G" jako "G" :-) 

Protože české se odkudsi generují, tak se mi na to nechce sahat, protože by tím pádem byla nekonzistence mezi originálními a těmi na serveru. I když jen v názvu.

[HaLuMa]

Omezeni sloupcu rychlosti nepomuze, razeni podle pocitaneho sloupce (coz kazdy tag je) pochopitelne zpomali razeni, ale ne samotne nacitani seznamu.

 

Tam je spise problem, ze nacitani je v principu nahodne poskakovani po databazovem souboru. Kdyz je velky, poskakujes vice, vice I/O operaci, mene se toho vejde do cache.

[Arne1]

 Ty mas v polygonech spoustu prace a mas na to bat, jak jsi psal a jsi ochotny se tomu venovat. Tak proc ne.

Ten baťák je pouze na skládání polygonů z nakreslených větví a uzlů.

[HaLuMa]

Sorry, není tam napsanej Gord ale Geby (holt "G" jako "G" :-) 

Protože české se odkudsi generují, tak se mi na to nechce sahat, protože by tím pádem byla nekonzistence mezi originálními a těmi na serveru. I když jen v názvu.

Bylo to vygenerovane z nejakych dat, ktere jsem mel a nemam je nijak aktualizovane. Ergo, jeslti to generujes z nejakeho udrzovaneho zdroje, treba z OSM, dalo by se to klidne pouzit. Jen to chce delat nejakou rozumnou redukci bodu (pred tim, nez se z nich vyrobi sousedni polygony, aby to sedelo.)

[HaLuMa]

ale ted bych to asi nekomplikoval, zkusim to jen nejak prevest na UTF a novou verzi dat poresime pozdeji.

[taxoft]

Mi trvá načtení listu 45s. Mám tam v zafiltrovaném listu cca 110000keší, Filtr s vynechanými eventy, bez archivovaných. Celkem má databáze 1,4 GB. Je to na asi 5 let starém notebooku, ale s SSD.

Jak máš velkou DB? Nemáš tam řazení keší podle nějakého neindexovaného sloupce? Třeba dle FP seřadit trvá neskutečně dlouho.

A otevíráš opravdu ten seznam pomocí List->Open list? Tedy pouze seznam GC kódů nad prázdným oknem?

[HaLuMa]

aha, to jsem nepochopil, ze myslis tohle. Tak to se podivam.

[HaLuMa]

A otevíráš opravdu ten seznam pomocí List->Open list? Tedy pouze seznam GC kódů nad prázdným oknem?

Mas recht, tohle je opravdu hodne pomale. A s tim neco udelat pujde.

[HaLuMa]

Tak jsem s tim nahravanim seznamu neco udelal. Puvodne to bylo opravdu hodne pomale, u mne mi vzorek cca 62000 kesi v GGT trval 5:42 minut!

 

Po uprave je to 0:44. Lepší?

[taxoft]

Už se na tuhle opravu těším pátým rokem. Tak s jásáním počkám, až si jí vyzkouším na svém počítači...

[Arne1]

ale ted bych to asi nekomplikoval, zkusim to jen nejak prevest na UTF a novou verzi dat poresime pozdeji.

Jestli na to nemáš čas a chceš to jen převést na UTF, tak bych to klidně udělal. Jen jsem se do toho nechtěl cpát.

[Arne1]

Tak jsem s tim nahravanim seznamu neco udelal. Puvodne to bylo opravdu hodne pomale, u mne mi vzorek cca 62000 kesi v GGT trval 5:42 minut!

 

Po uprave je to 0:44. Lepší?

Apríl ?

[HaLuMa]

Ne, to není apríl. Ještě se dneska budu koukat, jestli mi stejný problém nestrasi i jinde.

Jestli ty polygony můžeš jen jednoduše převést na utf8, tak by mi to teď pomohlo, dík.

[Arne1]

Jestli ty polygony můžeš jen jednoduše převést na utf8, tak by mi to teď pomohlo, dík.

No tak jo... Ještě že existuje iconv :-)

Víc jsem do toho nesahal, i když by se to dalo zkrátit