599 odpovědí na toto téma

[tarmara]

V tuhle chvíli má prioritu LiveMapa, s ní tam přidám to řazení posledních 15 logů. Až bude plně funkční LiveMapa, tak bych chtěl řešit výkon a přitom tam můžu přidat možnost zvolit si, zda chcete upřednostnit údržbové logy. Akorát teda budu pak potřebovat připravit ten sql dotaz, nebo ten co tu byl od tarmara, tak je hotový?

Live mapa bude super, u starého doplňku jsem ji měl vypnutou, protože měla slabý výkon - nestíhala načitat kešky při jízdě autem. Ale to bylo možná špatným/neoptimalizovaným načítáním z db. Pokud jde o psaní SQL (ať už pro live mapu nebo pro načítání logů), tak velmi rád pomůžu. Ale budu potřebovat vědět jak bude dotaz použitý, jaké bude mít parametry a co bude možné optimalizovat v db a co v aplikaci. 

Ten dotaz na složitější vybírání logů byl možná hotový, možná ne. Záleží na tom, jak bys ho v doplňku používal.

Tento příspěvek byl upraven od tarmara: 30 leden 2020 - 13:17

[Y&MD]

Za pomoc budu moc rád, díky.

 

Ty logy se aktuálně načítají opravdu jen takto:

SELECT type, finder, logtext, dt FROM geolog WHERE id = ? LIMIT ?

Takže moje super úprava bude:

SELECT type, finder, logtext, dt FROM geolog WHERE id = ? ORDER BY key DESC LIMIT ?

Záměrně tam mám key a ne dt, protože alespoň dle mých zkušeností, řazení podle intu je rychlejší než podle data.

 

Pokud ten tvůj dotaz připravíš tak, aby na vstupu byl jen počet logů a id keše a výstup bude type, finder, logtext, dt, tak se ti žádné meze nekladou.

 

Našel jsem tuhle implementaci SQLite pro Android: https://github.com/r.../sqlite-android
takže pokud budeš chtít, můžeš využít všechny možnosti SQLite dané verze.

 

Co se týká výkonu LiveMapy, večer ti sem hodím, jak vypadá ten původní dotaz.

[tarmara]

řazení přes číselnou hodnotu je rychlejší než přes datum. já používám cast(gs_logid as integer), protože to je unikátní id přímo od GS a nemělo by se měnit. Navíc nevím jak přesně GG přiřazuje key jednotlivým logům a jestli není teoreticky možné, aby mladší záznam měl nižší key než starší (různé přemazávání logů, načteš starší logy déle než mladší). To že gs_logid a dt jsou definované jako TEXT je trošku potíž, řešitelná CAST fcí. navíc dt obsahuje jen datum, nikoli čas a v rámci dne se nedají logy deterministicky řadit. 

 

To loadování logů při importu/čtení se pouští pro každou keš zvlášť? Tzn. iteruješ přes množinu ID dotazy se změnou parametru v "WHERE id = ?"? Nebo je aplikace schopná i dávky - pustilo by se to s podmínkou "WHERE id in (?)" třeba pro 50-100 keší najednou? Pro těch řádově 10-15km je to 100-5000 keší, možná by to stálo za performance test co bude rychlejší. Možná se to musí pouštět pro každou keš zvlášť kvůli generování GPX. Možná řeším nepodstatnou věc a jdu s kanonem na vrabce. Možná je db režie tak malá, že se vyplatí logy loadovat dělat keš po keši.

 

Do pondělka jsem na horách, klidně mi to nacpi do SZ, ať tu neplevelíme téma technickými detaily.

 

Binárky sqlite pro android jsou dostupné i zde https://www.sqlite.org/download.html - ale já do vývoje na droidu vůbec nevidím a tvůj zdroj je správný. Já jsem jen zvyklá brát sw přímo od zdroje (z domovských stránek)

Tento příspěvek byl upraven od tarmara: 30 leden 2020 - 15:51

[nalano]

Dovolím se přispět svým selektem, který vrátí poslední log každého typu, všechny logy přátel a pak poslední logy bez určení, to vše v maximálním počtu x logů.

Má to na vstupu id keše (na 3 místech, a seznam přátel). Můžete se tím inspirovat nebo to zahodit nebo to použít. 

SELECT type, finder, logtext, dt FROM (
SELECT 1 xx, a.* FROM geolog a WHERE a.gs_logid IN (SELECT max(gs_logid) FROM geolog WHERE id = 'GCxxx' group by type) --z každého typu logu ten poslední
UNION
SELECT 1 xx, a.* FROM geolog a WHERE id = 'GCxxx' AND finder IN ('Friend1', 'NaLaNo', 'xxx') --vrátí logy přátel
UNION
SELECT 3 xx, a.* FROM geolog a WHERE id = 'GCxxx' --všechny logy
ORDER BY xx, dt desc, gs_logid desc  
LIMIT 15 --seřadí nejdříve důležité logy, pak poslední a celkem vrátí x záznamů
)
GROUP BY dt, gs_logid 
ORDER BY dt DESC, gs_logid desc --odstraní duplicitní logy a seřadí je od nejnovějších

Tento příspěvek byl upraven od nalano: 04 únor 2020 - 21:27

[HaLuMa]

řazení přes číselnou hodnotu je rychlejší než přes datum. já používám cast(gs_logid as integer), protože to je unikátní id přímo od GS a nemělo by se měnit. Navíc nevím jak přesně GG přiřazuje key jednotlivým logům a jestli není teoreticky možné, aby mladší záznam měl nižší key než starší (různé přemazávání logů, načteš starší logy déle než mladší). To že gs_logid a dt jsou definované jako TEXT je trošku
 

 

Key je ve skutecnostu _ROWID_, tedy prirozeny identifikator v b-tree strukture, kterou SQlite uvnitr sebe pouziva. NEni to tedy klasicke databazove policko, i kdyz se tak tvari. Kdykoliv se ma do tabulky vlozit novy zaznam, tak se toto cislo prideli jako o 1 vetsi, nez dosavadni nejvyssi hodnota.

 

Az kdyz se dosahne hodnoty 9223372036854775807, az pak se pokousi hledat díry v ciselne rade.

Takze teoreticky to chronoligicke byt nemusi, prakticky ale bude. A razeni podle key by melo byt nejrychlejsi. (V praxi tam bude mnohem vice zdrzovat neco jineho.)

[nalano]

Vzhledem k tomu, že řazení probíhá až na omezené množině logů (řádově desítky záznamů), tak rozdíl v rychlosti podle key nebo podle dt bude minimální. 

[Y&MD]

Jak jsem slíbil, dávám sem ten dotaz, ať můžete případně přemýšlet, jeslti by se to nedalo udělat lépe.

 

Popíšu to na příkladu LiveMapy, tam ten výkon bude mít vliv, ale zároveň stejný dotaz použiju i na normální načítání, ať už pro Import nebo jen pro Zobrazení.

 

Jako vstup berte 4 body (8 hodnot), udávající výsek mapy. V LiveMapě to vypadá takto:

String[] cond = new String[]{
    String.valueOf(update.getMapBottomRight().getLatitude()),
    String.valueOf(update.getMapTopLeft().getLatitude()),
    String.valueOf(update.getMapTopLeft().getLongitude()),
    String.valueOf(update.getMapBottomRight().getLongitude()),
    String.valueOf(update.getMapBottomRight().getLatitude()),
    String.valueOf(update.getMapTopLeft().getLatitude()),
    String.valueOf(update.getMapTopLeft().getLongitude()),
    String.valueOf(update.getMapBottomRight().getLongitude())
};

update je proměnná, co pošle Locus, resp. jedna část proměnné, ale v podstatě je to definování toho, co aktuálně uživatel vidí v Locusu.

 

Pro Import a Zobrazení se ty body počítají takto:

Float radius = (float)Settings.filter_radius / 70;
String[] cond1 = new String[]{
        String.valueOf(mapCenter.getLatitude() - radius),
        String.valueOf(mapCenter.getLatitude() + radius),
        String.valueOf(mapCenter.getLongitude() - radius),
        String.valueOf(mapCenter.getLongitude() + radius)
};
String[] cond2 = new String[8];
cond2[0] = cond1[0];
cond2[1] = cond1[1];
cond2[2] = cond1[2];
cond2[3] = cond1[3];
cond2[4] = cond1[0];
cond2[5] = cond1[1];
cond2[6] = cond1[2];
cond2[7] = cond1[3];

Settings.filter_radius je to co nastavíte jako radius v Nastavení doplňku. Přiznám se, že netuším, proč je tam / 70, jestli je to zjednodušení na kružnici, nevím. Takhle to prostě bylo.

 

A teď ten dotaz, tenhle je z LiveMapy, u Importu a Zobrazeni je obdobny:

SELECT geocache.id, geocache.x, geocache.y, geocache.name, difficulty, terrain, cachesize, cachetype, cachestatus, dtfound, author 
FROM geocache 
LEFT JOIN waypoint ON geocache.id  = waypoint.id 
WHERE cachestatus IN (0) -- pripadne 1, 2, podle nastaveni

-- ted prijde cast pro filtrovani, uvadim jen pro uplnenost
-- AND dtfound = 0
-- AND author != ...
-- AND cachetype IN (...
-- AND cachesize IN (...
-- AND terrain IN (...
-- AND difficulty IN (...

-- a ted vyber kesi podle radiusu
AND (
(CAST(geocache.x AS REAL) > ? AND CAST(geocache.x AS REAL) < ? AND CAST(geocache.y AS REAL) > ? AND CAST(geocache.y AS REAL) < ?) 
OR (CAST(waypoint.x AS REAL) > ? AND CAST(waypoint.x AS REAL) < ? AND CAST(waypoint.y AS REAL) > ? AND CAST(waypoint.y AS REAL) < ?)
)
GROUP BY geocache.id

V té poslední části si myslím, že je asi největší zpomalení, ty přepočty na REAL atd. Tam bude asi prostor na tunning.

 

[HaLuMa]

Proč je výsek mapy definován čtyřmi vrcholy obdélníku, když stačí jen dva protilehlé vrcholy?

Ta poslední část je právě to, co dokáže dramatický zrychlit ten rtree index, co zabudované SQLite v androidu neumí. Pomocí něj bys jedním selectem získal klíče keší/waypointu, které jsou v tom obdélníku. O tom, jak je to rychlé, se můžeš přesvědčit v Geogeti ggmap.

Tento příspěvek byl upraven od HaLuMa: 30 leden 2020 - 22:49

[Y&MD]

Stačí, já vím, takhle je to v tom původním kódu, zatím jsem do toho nesahal. Je to na pořadníku.

 

S tím rtree počítám, akorát mi s tím budete muset pomoct, tohle jde mimo mě a nemám s tím žádnou zkušenost.

[HaLuMa]

V pohodě, az to bude aktualni, tak ti ta SQL pošlu.

[gord]

K tomu rtree indexu me napadlo - vim o par lidech, kteri pouzivaji Locus i AD. Locus do databaze (zatim) zapisovat nemuze, ale AD ano a ten v tuto chvili index aktualizovat nemuze, protoze Ludek zatim odmita pouzit jiny nez interni engine. V tom pripade by asi mohlo dojit k tomu, ze plugin bude pouzivat nekonzistentni data/rtree index.

[HaLuMa]

...ale jen pro data, ktera AD zmenil a Locus by sahal do stejne databaze. Pak by Locus zmenena data pres index nevidel.

[hlavsic]

Pravdou je, ze kdyz jsem jeste mel AD spolu s Locus v telefonu, tak oba sahali na stejny geoget.db3 soubor.....

[gord]

...ale jen pro data, ktera AD zmenil a Locus by sahal do stejne databaze. Pak by Locus zmenena data pres index nevidel.

 

Ano, tak jsem to myslel. Tyka se to i aktualizace, pak muze byt v indexu jina poloha nez je skutecna.

[Y&MD]

Jsem rád, že na moje oblíbené číslo 13 vyšlo zprovoznění Živé mapy. Výkon není úplně dle představ, ale to je další věc na programu. Takže pokud má někdo chuť testovat, je tam verze 0.13.

 

Trocha technické omáčky:
Předělal jsem všechny tři režimy na jeden „engine“, abych si ulehčil práci při odstraňování chyb a zároveň vylepšování bylo jednodušší.
Načítání keší z db je ve všech třech režimech totožné, pouze u Živé mapy se neaplikuje rádius, ale výřez obrazovky. Tady se omlouvám autorům předešlého doplňku, že jsem tu uvedl, že se to počítá ze 4 bodů – je to tam totiž dvakrát za sebou, tak mě to zmátlo, ale ve skutečnosti se to počítalo jen ze dvou bodů (TopLeft a BottomRight). V režimu Import se po zpracování zobrazí v Locusu dialog uložení bodů, pokud máte zvoleno natahovat všechny informace, jsou součásti dat i listingy, logy atd. Režim Zobrazit keše je identický jako Import, ale na konci se nezobrazí dialog a nenatahují se listingy apod. Režim Živá mapa je roven režimu Zobrazit keše, jen s omezením na výřez obrazovky a vnucený neviditelný mód (nejsou zobrazovány žádné informace o průběhu), a pochopitelně reaguje na posun obrazovky.
Pokud se tedy podaří zlepšit výkon načítání z db, projeví se to ve všech třech režimech, ať už používáte kterýkoliv.

 

V té aktuální verzi 0.13 se do Živé mapy zapojuje trochu limit keší a myslím že i rádius, takže pokud by vám nenačítaly všechny keše, zkuste s těmito hodnotami pracovat, případně vypnout úplně filtr, nebo je nastavit na nula. Je to věc o které vím a opravím ji, až budu měnit sql dotazy atd.

[tarmara]

Rychlé testování a opět klobouk dolů. Živá mapa (LM) je zatím subjektivně rychlejší než načítání keší do mapy v aDrake. Zkusím ji dneska otestovat v autě v kombinaci s automatickým zoomem v navigaci. 

drobnosti spíše ergonomického rázu:

• pokud v Locusu pustím LM a locus vypnu, tak mi v systému zůstane viset hláška "LM zapnuta". Pokud LM před vypnutím Locusu vypnu, tak zmizí i hláška.
• pokud v Locusu aktivuji LM, tak se hned nezobrazí keše. Čeká se na pohyb kurzoru v mapě. Možná by stálo za to hned po zapnutí aktivovat načtení keší a nečekat na pohyb kurzoru.

[hlavsic]

Tak ja nevim.

Ale nejak se mi nedari zivou mapu zprovoznit. Zapnul jsem ji v doplnku a v Locusu jsem kliknul na ikonu. Objevilo se mi, ze Ziva mapa byla zapnuta. Ale kese se neobjevily :-(

Napada nekoho, co delam spatne??

[Y&MD]

- Nemas zapnuty nejaky filtr na typ, velikost apod?

- Zkus posunout mapou, jak píše tarmara, čeká to na tu událost posunu obrazovky (opravím).

- Není možné, že v dané oblasti nemáš žádné keše v db?

[HaLuMa]

technicka poznamka: AD take nepoouziva prostorove indexy, takze by to melo byt srovnatelne rychle. Jen pri vetsim priblizeni dela AD fintu, ze nacita vetsi oblast nez je prave zobrazeny vyrez mapy. (takze je tim padem malicko pomalejsi). Takze kdyz pak o kus posunes mapu, nemusi se kesky hned nacitat znovu.

[hlavsic]

- Nemas zapnuty nejaky filtr na typ, velikost apod?

- Zkus posunout mapou, jak píše tarmara, čeká to na tu událost posunu obrazovky (opravím).

- Není možné, že v dané oblasti nemáš žádné keše v db?

Filtr jsem mel v doplnku, tak jsem ho vypnul - NEFUNGUJE

Posunuti nezabralo.

Kese tam mam urcite, IMPORT normalne funguje.

V LOCUSU se podle me nic nezapina, nebo jo?