This object is in archive!
Faster application startup with lots of tracks?
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
The same question
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.
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.
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.)
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.)
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.
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.
I have the same problem and I have all tracks NOT visible. It takes 30 secs to load 300 invisible tracks in startup.
I have the same problem and I have all tracks NOT visible. It takes 30 secs to load 300 invisible tracks in startup.
Joao, I'm unable to simulate your problem... Please follow instructions here: http://docs.locusmap.eu/doku.php?id=manual:faq:issue_reporting
Joao, I'm unable to simulate your problem... Please follow instructions here: http://docs.locusmap.eu/doku.php?id=manual:faq:issue_reporting
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
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
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 :)
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 :)
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 :)
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 :)
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.
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.
Replies have been locked on this page!