Remarkably increased load times for mapitems category/directory listing since Locus 3.18.3

Bucky Kid shared this problem 2 years ago
Solved

Hello, since this version I observe significantly increased load times of POI categories from mapItems.

Measured for 5892 waypoints category (in attachment for test) the load times were

Locus 3.18.4 / 3.18.4.1 beta - 1:45 / 1:56

Locus 3.18.1 - 0:22

On old phone it takes even many minutes to load previous POI categories on start (about 2000 waypoints in total)


Also the category listing load time seem increased (not measured).

Comments (5)

photo
1

Hello Bucky Kid,

you have these files in your device ... we are just now releasing new version 3.18.5, so please try it again with this version (mapItems and also POI folders) and let me know. Mainly in case of folders, it should be better as I was working on it right yesterday evening. Thank you!

photo
1

Hello Menion, POIs load performance is still poor in version 3.18.5.

Reference category load times 1:43 and 1:55 (5x slower than 3.18.1).

POI list refresh speed is acceptable.

photo
1

Hello, thanks for a test.

Indeed on my own device is difference as well ... 20s vs little more over 1 min.


I did few tests and seems that major influence is enabled automatic fill of elevation values which was enabled later. In case of points, it has no huge benefit. It was enabled mainly for tracks, where thanks to this, is visible chart and all elevation values in cases, track itself do not have elevation values.


And now the good question: how to solve it. I see slowdown as a good exchange for available elevation value (as I wrote, mainly for a tracks). Almost 6.000 points loaded in one minute is quite good result even with filled elevation. But your point of view will be different, right? :)

photo
1

Thanks Menion for investigation. For tracks I see sense but for plain POIs the ttine cost is too high.

On old phone with 2 core the startup time is over 5 minutes for only 3 categories active.

I'd suggest to decrease startup time either by caching the elevation data somewhere or filling them in background after user interface is ready or use the fill only for tracks. Maybe storing elevation data in .gpx permanently once filled from srtm would be best solution.

photo
2

Hello, understand ...


All options brings some complications to me. Oki, for now I'll disable this feature.


It was enabled before, because there were some people that complained that loaded tracks do not have visible chart, even they have required HGT files download. It should be anyway solved by better visibility of "fill elevation" button in track detail.


Anyway thanks for useful bug report. Now I know that I have to be even more careful with filling elevation data on background!


Btw: loading points from database will be a lot more faster in this case!