This object is in archive! 

Faster application startup with lots of tracks?

dean gaudet shared this question 6 years ago
Answered

is there any way to improve the application startup time when i have hundreds of tracks imported?


i tend to have 250 to 500 tracks in the database, and i end up pruning them not because i'm running low on storage, but because it takes so long for locus (pro) to restart.


it would be cool if tracks were more demand loaded depending on where on the map i'm looking at.


thanks

-dean

Replies (9)

photo
1

Hi Dean,


are your tracks in your database, i.e. do you manage them in the tracks tab of the data manager or do you display them as "items" (stored in Locus/mapItems directory and managed in the items tab)? Amount of data in the database shouldn't have an influence on the app startup.

photo
1

tracks tab, not items. occasionally i have some points, but not many... i don't use the items tab.


i just did a test: used a nexus 7 (with android 6) and installed locus pro. a fresh install takes about 4s to restart on this tablet.


to restart the app i'm using back arrow twice, followed by swiping the task away from the recent task history.


then i added 150 tracks and restart time was ~18s. i deleted 50, and restart time was ~12s. i deleted another 50 and restart was ~8s. so it looks like on this tablet the app loads about 50 tracks every 4s, plus the baseline ~4s startup time.


my main device is a galaxy s5, and the load time seems somewhat similar but i didn't want to mess with deleting/restoring tracks from my main device so i haven't tried any timings there.


during restart the dialog spends its time between 60% and 69% where the last item in the list is effectively "loading tracks".


i can provide you the .zip file i used to load the tracks but i'm not sure it matters -- for the test i used 150 tracks exported from locus pro recordings (previous hikes), but i've seen the same with tracks loaded from many other sources (i preload lots of tracks from gpsies, wikiloc, peakbagger, hand-created on caltopo etc.)

photo
2

if you keep all your tracks active, i.e. visible on map, then Locus has to load them all when restarted - this takes time. Keep your tracks supply inactive and use just those tracks you need actually.

photo
1

I have the same problem and I have all tracks NOT visible. It takes 30 secs to load 300 invisible tracks in startup.

photo
1

Joao, I'm unable to simulate your problem... Please follow instructions here: http://docs.locusmap.eu/doku.php?id=manual:faq:issue_reporting

photo
1

so yeah, if i hide all the tracks the startup time is fine, but then the app isn't as useful for me: i don't necessarily know the names of the tracks nearby to unhide them... so i can't see which trails i might have mapped near a trailhead.


i looked around a bit to see if i could unhide some tracks based on the current position, and i found that if i sort a track folder by "distance to start", then "select first X" it selects at least X tracks that are nearest... but i don't see a way to unhide the ones which are selected (i only see copy/move/delete/export/statistics/merge for bulk options). this would probably be an easy feature to add... but it's kind of cumbersome.


have you considered loading only the min/max lat/long, 4 values, and doing range comparisons based on current display window? what would be really nice is to have the track loading in an async thread according to current map view, tracks could appear as they are parsed, but let the rest of the UI keep going.


thanks

-dean

photo
1

oh hah immediately after posting i see the "first X tracks" on the hide/unhide button.


ok now i see how you intend this to work... but it's still awkward :)

photo
1

Hi Dean,


we intend Locus to work for as many users as possible. Not all of them use their own "mapped" track network - they orient by a map instead. You probably live in an area where no detailed map is available and that forces you to make your own map. Okay, but then you have to count with the open database with millions of trackpoints carrying a great amount of information that Locus must "read" every time you launch it. If you need your own map, then become an OSM mapper and upload your tracks on the OSM server. There are many providers rendering maps from OSM source - our LoMaps as well. And furthermore - you share your mapping efforts with others :)

photo
1

you don't need to load millions of track points, you need to load 4 per track (lat min, lat max, long min, long max) and do 4 comparisons per frame. obviously you need to compute those 4 points, but that's easy enough to do when you're importing the track into the database.


my use case isn't what you described either: i live in the western US. there is OSM coverage for many popular trails, however many destinations are not mapped, nor is there necessarily an established trail. most of the tracks i load i've found on one of many sources on the internet: i do not own the copyright on those tracks. i've never hiked the track either. it would be supremely irresponsible for me to upload someone else's track, one i've never hiked before, to OSM. i definitely have contributed to OSM after i've tested a trail and if the trail is maintained/official.


i don't want to render maps for offline use: your OSM-derived offline maps are generally good enough provided i've got an idea of where i'm going. the 20m topo on your maps isn't frequently enough to be certain a path is within my skill set: but when i'm planning ahead of time i can consult more detailed topo, and find paths which others have found favourable/preferred. i'm using the tracks more as routes. while i'm in the middle of a hike the previously planned route serves as a useful indicator of my progress, and whether i can take a long break to enjoy a view, how far to next water source, or if i'm going to be in danger of running out of light or such. a map isn't as good at this: it's better at showing all possible routes. if maps were good enough alone then we wouldn't have nav software to tell us which turns to take while driving.


-dean

photo
1

Hi Dean, for sure, nobody wants you to upload someone else's tracks to OSM. Okay, now it's clear what your intentions are (and of others in this thread as well). We'll have to cope with it somehow and as you see in the end, the main developer has been informed.

photo
1

I also have horrendous startup times... along 20 seconds or some such... even with no tracks actually enabled. It's quite a sad affair for power users really. Locus superslow database accesses wouldn't matter so much if only it were at bit more multithreaded in general. Why can't it be ready for action immediately and keep reading the tracks and points databases in the background?

Same goes for other stuff, like deleting points (10 seconds each... come on... even my Commodore 64 could do this in a millisecond), general track rendering (1-fps-horror-slowness when styles are used and clipped) and for god knows how many other things. We have smartphones with 8+x cores these days and yet Locus insists on doing everything on the main UI thread, always blocking the whole program and making its users wait.

I only wish the programmers were "power users" as well... with reasonably sized track and point databases and lots of things to do with Locus while out and about. Obviously, none of our performance concerns matter much when you just test the thing with five tracks and twenty points on your warm and comfy couch.

It's almost 2016... and Locus still remains a single-threaded monster like software was in the last millenium. It probably qualifies meanwhile as one the most unresponsive UIs ever. Still the best navigation solution of course... but it could be so much snappier if only more care was put into multi-threading and general performance.

photo
1

I know joeloc, thanks for an opinion.

Replies have been locked on this page!