Street name and lane marker disappear.

[PaulStets]

The street name and lane marker show up like normal when I start riding, and once I turn off of that first road, they disappear and never come back.

Android 5.1.1, OsmAnd version 2.6.5

Video: https://drive.google.com/file/d/0B_epabEezdJreFV4Ql8wLWd6eEk/view?usp=sharing

[tazva]

I just presumed it may have been an offshoot, because it will sometimes take 2..5..12 seconds for the map to colorize properly, as I am travelling. In other words if I am travelling south, the bottom half of the screen will be tiles of day mode, which eventually turn dark. I just presumed the high CPU load was causing it to "take awhile".

Your description of it matches mine, it is a very good description.

[sonora]

To get back to the original issue: Are we quite confident the high CPU usage is

• (1) connected to when the device is or was in motion (i.e. does not occur when the device is at rest from the start)
• (2) connected to the street name display being enabled or disabled?

[tazva]

On point (1), It absolutely occurs regardless of motion--while completely at rest.

Here's a series of tests I ran lastnight using the same methodology as before. I only plotted load this time, no speed (no motion..). Device was powered on and left abandoned for periods of time. Capture intervals for data points was 10sec. I clipped out the first 30 seconds of boot time, as that would prejudice the chart. What is seen below is the device simply at rest:

There are four tests, all of them the same except for test 3. For this particular test, I blocked the GPS from being able to receive a signal. This shows OSM doing something, even when no GPS data is being parsed. 30% load with 0/0 for satellite signal.

As to point (2), I can run the same test with the street display disabled.

[sonora]

Very interesting. So it seems what you see is not related to map rendering, as the map remains stationary. We must be doing something else continuously using lots of CPU.

Not sure I can reproduce the observation though: On Samsung devices, and using Samsung's built-in "Active apps" monitor, OsmAnd's CPI usage seems to strictly drop to 0.00% when OsmAnd is in the background (and the app monitor is in the foreground): When in motion after latest 3 seconds from when switching from OsmAnd to the "Active apps" app. And when performing that switch while at rest, the Active app monitor immediately shows OsmAnd using 0.00% CPU, which seems to indicate that is also the value for when OsmAnd is in the foreground.

So I cannot actually confirm the observation OsmAnd is using any CPU at all, unless

• you are in motion and the map needs to get panned and re-rendered
• you are in motion and in an app profile with street name display active (like our car profile by default), which seems to add extra and excessive CPU load (we currently refresh the street name lookup rather frequently every 10m of position change or so)

[tazva]

This is a Samsung tablet I'm using, as I've stated before. I can also reproduce it on a Samsung Note 4 Edge, but I used the third party app to provide objective raw usage of hardware, which could then be written to a log file. I have no idea how Samsung's applet work.

Now, as promised, here's my data from point (2), where I disabled street display.

Completely motionless with street displays disabled, there appears to be no difference with the previous test (street displays enabled).

Combining these results, with the previous--particularly noting the CPU usage with GPS signal blocked--as an outside analyst, I can only conclude something in the code is burning up CPU slices in a loop, and it only gets worse when there's GPS data stream involved. That it grows significantly with higher speeds (thus, more GPS data/longer distances between points), only adds to the theory.

Again, baseline study of the device without OSM+ loaded, shows 0-4% CPU usage at most--typically 0-1%. The other 20-40% is coming from OSM+, for whatever reason. I've run a few other apps, including Nav apps, just to test. They don't appear to have the strain/drain OSM+ does. I will examine them in more detail.

[CJTmmr]

I have seen the high CPU-use as well on Samsung Galaxy Camera 2 (in latest nightlies) In my experience: after a fresh start the CPU-use stays high for a long time, even when OsmAnd is no longer on foreground. The Street name and Lane marker are not shown in follow-me-mode. But even when the map is on a fixed position the CPU-use stays high. I guess the disappearing streetname is a consequence of the high CPU-use, rather than a cause.

Only after a search for address or POI is completed, the CPU-use goes back to normal... Is it possible that at start-up some initial search-proces is started, which somehow does not end?

Good luck investigating.

[tazva]

Thanks for that input CJ, I will try the POI/address search you suggested, to see if that does something.

[scaidermern]

To the developers: Please just use a profiler. It shouldn't be too hard to identify the cause of this high CPU consumption. Fixing this bug will help a lot of your users and improve one of the main point of criticism of OsmAnd (= consuming lots of CPU / battery).

[tazva]

Rounding the corner on almost a year old, I wonder how the progress is? I haven't had a chance to do any additional debugging since my last post, I've been very busy :(

I can no longer reliably use OSMand for navigation purposes due to the CPU load. A couple of times in the past month I've needed to navigate somewhere and would input the location. Inevitably I'd choose a destination, and it would take ages to calculate. Eventually it worked, but I would have to change route due to some issues, and recalculation simply took forever--and every intersection was a recalculation, so this forced it to just keep lagging and lagging. Ended up just killing it off and toggling over to google maps, it was up and running to my nav point within 3 seconds, with no issue.

I simply use OSMand for general quick-visual reference now, the CPU overhead is simply too great to do anything else with it. It still burns a hole in my hand if I use it on a more modern device, where the battery drains as quickly as pouring water from a glass.

[vshcherb]

I guess here there were measurements about navigation mode without calculating route, so in that case "reverse geocoding" is happening every 50 meters which is very CPU expensive for each call. Unfortunately no progress was made in that direction

[CJTmmr]

CPU load is high sometimes, even while navigating along a calculated route. And even while standing still, even when OsmAnd is running in background..... Unfortunately

[tazva]

@vshcherb as @CJTmmr and some others have pointed out, it's not just in one mode, it's in every mode, whether calculating or not, whether in navigation mode, or in exploration mode. Something is clearly going on. Seeing all of the new bugs popping up, all in some way relating to 'slowdown', on brand-new multi-core very fast devices... this is pointing to something eating up processor time.

I can play HD games on my new phone and use less battery than OSM will just driving around. Yes, it is unfortunate no progress has been made to route this out, as mentioned last year, this will continue to plague OSM until fixed.

This issue was formerly tagged as a milestone event, but appears to no longer be the case. Rolling out new features is great, but shouldn't be a focus until foundational problems are resolved. Not sure why this isn't in the top 3 priorities. Just speaking from an outsider's perspective, of course.

[tazva]

While it's great to see OSMAnd is at a whole new version, and all sorts of features are being added, it would be great to fix underlying issues. Like #3898.