25 odpovědí na toto téma

[bohouscl6]

Přeji pěkný den. GG provozuji na ne příliš svižném netbooku a tak mi generování souborů pro výlet zabere dost času. Napadlo mne, že po aktualizaci databáze, kdy již jen generuji výstupy, bych mohl provést exporty SOUCASNE : Jeden puštěný GG by mi generoval POI.GPI Druhý současně puštěný GG by generoval GPX pro Oregona Třetí současně puštěný GG by generoval OVI do autonavigace. Technicky to možné je, mohu zadat práci a věnovat se přípravě věcí, oblečení a pod a po příchodu k PC už bude vše vygenerované (nemusím postupně zadávat generování jednotlivých výstupů) atd, Otázka zní : není to nic proti ničemu ? Nemůže současnou prací více spuštěných GG nad stejnou databází dojít k nějakému poškození databáze a pod ? Děkuji Bohouš

[dr.vota]

určitě to moc neurychlíš, spíš naopak, bude to trvat delší dobu než součet časů

[h0--]

Tak, předpokládál bych, že zdechne I/O u disku a CPU. Schválně si to zkus. :)

[medwyn_cz]

Naskripti si to do Combine a mas to vyreseny. Pojedou ti exporty pekne za sebou v serii.

[HaLuMa]

Vicenasobne cteni z databaze je naprosto neskodne, ale pustit to trikrat - to znamena trikrat vice diskovych operaci a trikrat vetsi spotreba pameti. A protoze notebook neni moc svizny, zjevne se mu nedostava obojeho uz pri spusteni jednoho GG. Takze ja bych to nazval kontraproduktivnim krokem. Uplne nejhorsi by bylo, kdyby do toho zacala schazet pamet a system by jeste zacal swapovat. Takoveto kousky si spis muzes dovolit, kdyz mas naopak silny pocitac.

[HaLuMa]

P.S. V poslednich dvou verzich byly o dost zmensene pametove naroky, coz by se mohlo pozitivne projevit prave na slabych strojich.

[bohouscl6]

HaLuMa napsal/a:
Vicenasobne cteni z databaze je naprosto neskodne

Děkuji za ujištění, chtěl jsem si být jistý.

Děkuji i ostatním za rady a postřehy.

Přidám pár dat : Acer Aspire One, 1.6 GHz, 1 GbRAM, SSD disk 16Gb

Spustil jsem současně ty tři exporty, k žádnému kolapsu nedošlo.

Paměťové nároky byly příznivé, zbývalo cca 350 Mb RAM. Obě jádra na 100 proc pokud pracovaly 2 a více GG současně. Při práci jednoho GG vytížení cca 55 procent.

Provedl jsem i doporučené měření tří samostatných exportů a následně všech tří spuštěných najednou, dopadlo takto :

OVI TOMTOM 2m 10s
POI.GPI 51m 26s
OREGON GPX 7m 5s
----------------------
součet 1 h 0 min 41 s

Všechny tři exporty najednou 56m 22s

Rozdíl není příliš veliký, o cca 4min byl rychlejší export všech tří současně spuštěných GG. V databázi mám pouze celou ČR a část Německa - Sachsen.

Ještě jednou děkuji za váš čas. Bohouš

[HaLuMa]

Proc je ten POI.GPI tak strasne pomaly? Cim to delas?

[gord]

Ten export POI je nejaky divny. Nemas to soucasne s POILoaderem? Ja mam podsatne slabsi stroj a POI cele CR (kese a WM) exportuji asi 15 minut.

[bohouscl6]

HaLuMa napsal/a:
Proc je ten POI.GPI tak strasne pomaly? Cim to delas?

Ano, stejně jako asi tebe mne rovněž napadlo po shlédnutí těch časů podívat se po jiných makrech dělajících totéž, jestli náhodou nebude některé svižnější.

Ze tří dostupných maker zvítězilo makro POI_export, čas 40 min

Příčinu proč to u mne trvá tak dlouho a na jiných PC je generování GPX pro poiloader výrazně svižnější netuším, možná za to trochu může použitý SSD disk, který je dost bídný, pomalý.

Znatelně mu pomáhá driver třetí strany (podobně jako pomáhal smartdrv ve Win95/98), ovšem při zpracování velkých objemů dat je jeho pomoc nevýrazná. Mojí současnou snahou je sehnat jiný SSD disk, jednak vyšší kapacita a druhak svižněší. Pokud se zadaří, mohlo by se to na těch časech projevit. Možná pomůže i rozšíření RAM na 2 Gb.

Uváděné časy se týkají pouze generování GPX pro poiloader. Není započítáván čas na přežvejkání GPX na GPI Poiloaderem.

Poslední verze Poiloaderu provádí generování GPI souboru velmi svižně (oproti předchozím verzím)

Děkuji oběma za zájem a snahu pomoci. Bohouš

[HaLuMa]

mezi uzivateli jsou i lide, kteri si pousti geoget obycejne flash klicenky, a mam pocit, ze i jim to beha rychleji. Sam mam na notebooku stare SSD, a beha to svizne, celou popsanou operaci bych odhadoval tak na rady minut. Pri takovychto operacich je vykon hodne zavisly na rychlosti nahodneho pristupu na disk, ale to by melo byt spise plus pro SSD.

[mikrom]

btw ten SSD co jsou v tetbookach se ani SSD rikat neda.. ale zkus nainstalovat ovladace FlashFire na netbookach, kde jsem ho instaloval bylo hodne znat zrychleni.. treba na vyjeti kontextovy nabidky jsem uz necekal 10 vterin X)
a poiloader nainstaluj ten nejnovejsi 2.6.1 nebo jak je ta verze, zda se o neco rychlejsi nez predchozi verze

[medwyn_cz]

No hlavne pokud pouziva nejnovejsi verze mych maker, tak tam je par neoptimalnich veci pri pouzivani knihovny VarSubst. To uz jsem trochu poladil, ale zatim nevydal. Neni cas a v blizke budoucnosti ani nebude

[bohouscl6]

mikrom napsal/a:
btw ten SSD co jsou v tetbookach se ani SSD rikat neda.

ano, je to tak. Sice to je SSD, ale ...

ale zkus nainstalovat ovladace FlashFire

Ano, tento driver jsem měl na mysli, že již používám, znatelně pomáhá.

poiloader nainstaluj ten nejnovejsi 2.6.1 nebo jak je ta verze, zda se o neco rychlejsi nez predchozi verze

Ano, používám, a JE znateně, měřitelně, svižnější.

Přidám RAM (a možná díky tomu budu moci zcela vypnout swap) a pokud seženu, dám jiný SSD, kterému už se bude moci říkat "Opravdový SSD". Děkuji za věcné a dobré rady, nevadí že už se jimi řídím.

Bohouš

[mikrom]

no pokud mas nejakej ten Aspire ONE, tak si na SSD moc zalusk nedelej.. je tam nejaka 1,8" varianta s nestandardnim "konektorem" resp nejakej ten ZIF nebo jak..

[bohouscl6]

mikrom napsal/a:
no pokud mas nejakej ten Aspire ONE, tak si na SSD moc zalusk nedelej.. je tam nejaka 1,8" varianta s nestandardnim "konektorem" resp nejakej ten ZIF nebo jak..

Ano, evidentně o tom víš hodně, výborně. Dlouho jsem sháněl skutečné hodnoty, jaké má stávající SSD disk a našel jsem to zde. Píšou 38/10 , což je fakt bída s nouzí. Už jsem objednal jiný SSD disk, ten má hodnoty násobně lepší, na výkonu by se to mělo projevit.

Zároveň vyměním 512 za 1 GB, čili výsledná velikost RAM bude 1.5 GB. Obě tyto investice se doufám znatelně pozitivně projeví. Pokud tomu tak bude, zveřejním zde nové časy exportů pro porovnání.

Děkuji za zájem, přeji pěkný den!

Bohouš

[mikrom]

bohouscl6: jo ten by tam asi mel jit.. jinak prenosovou rychlost zkus merit treba timto http://crystalmark.i...fo/index-e.html merej tim i v testech..
a RAMky taky neni nikdy dost

[gord]

Jeste me napadl jeden poznatek k tem casum. Mam zkusenost (Haluma mi sice vysvetli, ze to neni mozne, ale ja to vidim jinak ), ze po restartu GG je to rychlesji. A jeste rychlejsi je to po restartu PC a pravdepodobne i po VACUUM databaze. Cim je mene pameti, tim vic se fragmentuje a tim vic se fragmentace projevi, tak si to zpomaleni POI po celodenni praci meho NB vysvetluju. Rozdil je u me skutecne markantni - pred restartem NB to pracovalo 31 minutu, po restartu tataz mnozina kesi byla hotova za 17 minut.

[HaLuMa]

No, to Vacuum uz dneska nema takovy vyznam jako mivalo. Drive byla databaze GG v rezimu, kdy dochazelo k masivni vnitrni fragmentaci uvnitr toho databazoveho souboru. Po Vacuum se to prerovnalo. Nyni jsou ty databazove soubory delany jinak, a k te vnitrni fragmentaci by melo dochazet v mensi mire.

[S474N]

Jako docela me udivuje, ze je nekdo schopen cekat hodinu na export. To me uz "otravuje" i tech par minut a to mam udelane pres Combine, takze jenom kliknu a po skonceni nahrnu do navi.