This object is in archive! 

LM3/4 checks all maps unneccessarily taking ages

Michael Bechtold shared this problem 2 years ago
Solved

Even when only ONE map is added or changes, LM runs through all unchanged maps again. Which can take minutes.

Replies (21)

photo
1

Hello Michael,

once initialized map should be during next process handled very quickly. Do you have an idea, which map cause this slowdown during the start?

Map that was already correctly initialized during start, has some metadata stored in Locus/cache directory. Aren't you clearing this directory?

Jiří M. aka Menion

photo
1

Hi Menion,

it happens when a brand new map (i.e. one that has not been there before) into the maps folder under Locus, and it also happens when an existing map is replaced by a newer version.

I am not clearing any directory when I copy a new version there.

But anyway the 100 other maps should not be considered at all, as they do not change at all.

Kind regards

Michael

photo
1

Hello Michael,

"But anyway the 100 other maps should not be considered at all, as they do not change at all" > these maps still needs to be quickly tested if something has changed or not. But this should be really really fast.

During start when the app is stuck on initializing, isn't there a visible single map that causes these problems? As I remember, the app writes the name of the map that is currently initializing. Just asking because there may be a single map that causes all these troubles.

Menion

photo
1

Hi Menion,

I tried various devices:

- Android 9 is much faster than Android 11 - MUCH faster, when and IF running through all the maps

- with LM3 and LM4 there are cases when the splash screen with the init sequence and report not showing at all. With LM3 then Locus is fully available very fast, with LM4 is seems a bit slower

And mind: the Android 9 devices are older than the Android 11 ones ...

Any idea?

TXs and cheers

Michael

photo
1

Hello Michael,

to be true, I do not know.

Android 9 vs Android 11 > same maps? Same location in the internal memory, SD card?

A slower start of LM4 is possible (1 - 2 seconds, no more).

Anyway, my quick search shows that you are definitely not the only one: https://www.reddit.com/r/androiddev/comments/kpn68k/android_11_very_slow_file_access_performance/ .

Locus Map still works with the old system, so there really should not be a significant difference (until you modify the path to vector maps or HGT files in the Locus Map settings). This will anyway change next month(s). How bad it will be? Hope not too much. This is anyway another story.

Back to maps. Michael, I really do not know what exactly is a problem anyway if this happens always when you modify any map, the best should be if I create a version that will print out into log info about what is happening. Are you interested?

photo
1

Yes, please. I want to understand and hopefully get rid of this issue.

Thank you, Menion.

Cheers

Michael

photo
1

File Management in Android 11 is a disaster. You might have to give up dynamic altitude, hill shading and alike with SAF, where you deal with 100s of files, if not more. Go into the clarification with Google ASAP, I advise. Depending on that outcome and your test results, it may be already late ...

photo
1

Hi Michael,

if you like, have a look here: https://help.locusmap.eu/topic/23977-map-display-takes-forever

I have this problem since the update to Android 11 on my Pixel 3a ...

photo
2

Good to not be alone :-)

My maps are on internal SD (500 GB on S10), but there are MANY, hence the Android 11 slowdown is noticable, too.

I am highly concerned ...

photo
1

Martin, I already wrote my suspicion in the mentioned topic. It is only partially related to changes in A11 (most probably).

Anyway, Michael, try please this LM4 APK version. Install, start, set logging to file in expert settings, and close. Change something regards map as we talked about before and start again. Once, mentioned long init happen, send me please the last log where this should be recorded. Thanks!

photo
1

TXs Menion.

I installed this test version, activated the logging, then started again:

1) the first start to set the logging was pretty fast In comparison) - a longer pause at 11%, then a rush up to 100%, with NO running through the many maps AT ALL

2) the restart with the logging set was excatly the same - no running through the many maps at all

3) now adding a new raster map into the Locus maps folder - now the sloooow traversing all maps happens

4) next test with a CHANGED raster map in this same folder - again ALL many maps are touched.

I will send you the 4 files in a direct message to your mail account.

So curious about your findings ...

TXs and cheers

Michael

photo
1

Hello Michael,

thanks for logs.

My observations:

  • check on offline maps currently slow down the start of the app for almost 3 seconds. I tried to improve this a few months ago and this is best what I was able to do. Well, 233 maps is 233 maps.
  • as I see, validation of every map takes 300 - 500 ms, so if you have 233 maps, it is an almost 2-minute task

I understand it takes some time, but

  • app needs to be sure that map files are valid so it checks every file as fast as possible
  • this should really happen only when something changes, like in your case 3) and 4)

Complete init of a new raster map may take a few minutes and I thought we talk about this task. Anyway, what happens to you is just a current Locus Map behavior. Maybe there is some slowdown on A11 and this makes this task bigger pain than before. Truth is that on my device, init of the vector map, as I tested it right now with the same version, took on average 100 - 150ms, so 3x faster on 3 years old Pixel2 with A11 (63 maps in less than 10s), weird.

Hard to say how may I help here Michael, sorry. Disk performance is completely out of my control.

Menion

photo
1

Hi Menion,

thank you for the fast analysis.

I just sent you logs from an Android 9 device. And other than from the S10 logs that you got last night, here the maps are on external SDcard. And still this is much faster.

I know that you cannot chnage Android itself. But there is a significant risk that this issue will hit much broader soon ...

Also, as you say, only the changed maps should be analyzed. In the examples I sent, those 200+ maps are all unchanged, except 1 or 2. So, why analyze all the others??

And with the beta, the behaviour is back, that if no change happened, no checks are made. While the official release checks all 200+ maps, even when no change happened.

Only THIS behaviour is the reason for my issue report.

If I do change 200+ maps, I am more than happy to wait ONCE to get them analyzed ... once.

Can you pls. advise?

TXs and cheers

Michael

photo
1

What still irritates me: as soon as I set the storage to "private" (and install the maps there of course), the problems with slow loading are gone!

If it really should be due to the size of the SVG images (https://help.locusmap.eu/topic/23977-map-display-takes-forever#comment-95052), then that should not really make any difference - especially not on my Pixel 3a, where all data is in the internal memory ...

Und noch 'ne Frage an Michael Bechtold: Wo und wie sieht man (siehst Du), dass LM die Karten überprüft?!

Cheers!

Martin

photo
2

Hi Martin,

the init sequence pauses at 11% for a while without messages. And if the check amok happpens, then you see flashes of map names and % climbs to around 60% and then the init window disappears quickly and Locus is operational.

Cheers

Michael

photo
1

Thanks Michael,

have you tried whether it makes a difference if you install one or more maps in the "private" memory? You have the problems also under Android 11, if I have understood correctly ...

Martin

photo
2

I do not use private memory. It contradicts the use of maps by more than one app.

There are multiple issues meeting here:

1) Locus (release) runs through ALL maps although NOTHING has changed

2) and also in case only 1 or two have changed

3) the operation is slower by factors - I compare Android 9 SD versus Android 11 internal

Cheers

Michael

photo
1

I really do not know how to quickly help here Michael.

When any map changes (or is added), the app tests all maps. This test is really quick, as I wrote, it should be around 100 ms/map. What app do? It usually reads the map header and its file size and compares its known old values.

You wrote that "Locus (release) runs through ALL maps although NOTHING has changed", but I never noticed this behavior, so can't confirm. Does it happen all the time? Btw. The new version just published on Google Play, so give it a try.

The best solution I see? Simple > remove maps you do not use. You travel a lot, but isn't always better to download the new map before the trip?

photo
1

Hi Menion,

just tested with latest Playstore download from today, and there was no all map scan (there were no changes, either).

Hope this behaviour is stable.

BTW: I just investigated the Android 9 logs that I sent you this morning around 10.

For 200 .map files the check took 10 seconds, i.e. 50 ms on average. There are indeed factors in file system performance between those Android releases. I hope Google gets enough ass kicks from around the globe to do better ...

photo
1

Have you already registered the problem Google.

photo
1

Good evening Michael,

sad is, that in the new version is no change regards what we discuss here. I hope it was just some temporary glitch that won't happen again. And performance: weird is that values I wrote are from my Pixel 2 working also on A11. I use this device for almost three years and I did not notice any slowdown when updated to A11 last year. What you and Martin use? This looks more like a performance problem of your device manufacturer than Android itself.

Anyway 10s for 200 maps? Hmm, this is quite acceptable :).

Menion

photo
1

Indeed, Menion, I would not have sent a single message if that was the situation on my mobile! But the fast one is from a M5 tablet from Huawei from some years back (stuck on Android 9), while the slow ones are from Galaxy S10 (on Android 11) ...

Replies have been locked on this page!