Bug 342427

Summary:	Timing issues when large GPX file is loaded and option "Show tracks on Map" is used with GoogleMaps
Product:	[Applications] digikam	Reporter:	Quincy <bbc.quincy>
Component:	Geolocation-Correlator	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	caulier.gilles, metzpinguin
Priority:	NOR
Version:	4.6.0
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:	5.8.0
Sentry Crash Report:

Description Quincy 2015-01-02 23:54:05 UTC

I really like the new possibility of seeing the tracks on the map and therefore I used the feature heavily, but it was a pain to use it with larger files because of the following issue (demonstrating the bug with a small file):
- Loading a GPX file with ca. 23000 entries (about 3,5 MB) takes ca. 3 s to load (100% CPU on one core) in two different installations (digikam 4.4.0 and 4.6.0).
- Deactivation "Show tracks on Map" is directly in effect
- Re-enabling it always takes 11-14 s regardless of the number of on/off cycles.
- Closing the dialog (while option is activated) restores the situation: First load+display takes around 3 s, later enabling of the option takes about 4x as long.
- Leaving the option unset when closing the dialog reopens it without a checkmark, but still displays the track when file is loaded (which is another small issue) within the same shorter time.
- Closing it directly again (without activating the option in between) does not restore the initial timing, but takes the longer one.

Also there is an issue with loading multiple files at the same time which seems to be related:
- Load the same file as above (3 s)
- Load the file again (now displayed on top in another color): 12-15 s
- Deactivation of tracks: Immediate effect
- Re-activation of (both) tracks: 28 s (slowdown effect for both files together)

The effect gets worse with file size/entry number:
23000 entries --> 3 s (initial), 12 s (re-enable)
53000 entries --> 9 s (initial), 58 s (re-enable)
76000 entries --> 14 s (initial), 113 s (re-enable)
96000 entries --> 19 s (initial),  175 s (re-enable)

While the initial load keeps a quite constant rate of entries/time, the re-enable action suffers tremendously.

Please feel free to ask for other tests and/or clarification.

Reproducible: Always




This has been tested on two machines running KDE 4.14.3 with digikam versions 4.4.0 and 4.6.0

Comment 1 caulier.gilles 2015-05-20 09:36:24 UTC

Quincy ,

This file still valid using last kipi-plugins 4.10.0 ?

Gilles Caulier

Comment 2 Quincy 2015-09-08 17:58:48 UTC

Just tried it with kipi-plugins 4.12.0 (now on KDE 4.14.8 and digikam 4.12.0) and it is still reproducible as described.

Comment 3 caulier.gilles 2016-11-29 11:24:25 UTC

Can you reproduce the problem using digiKam Linux AppImage bundle ? The last
bundle is available at this url:

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

Comment 4 Quincy 2017-09-03 08:34:33 UTC

On the very same hardware as of my initial report, but now with DigiKam 5.5.0 it now takes 11s to load a file with 185000 waypoints, and 26s to re-enable. For a smaller file (70000 waypoints) it takes 4s to load and 5 to reenable.

So I can still see a slowdown for the re-enabling of tracks compared to their initial loading and it is still getting worse the bigger the file is. But as it is now way faster for both actions than before we could consider this bug solved. However I'm still curious why re-enabling is slower than the original load action.

Comment 5 caulier.gilles 2017-09-03 08:52:10 UTC

did you use reverse geocoding with geolocation tool ?

In face which options did you use exactly with this tool to load GPX ?

Also, i recommend to test the new 5.7.0 bundle, not the older one 5.5.0.

Gilles Caulier

Comment 6 Quincy 2017-09-03 09:17:57 UTC

5.7.0 is unfortunately not yet available in my distribution. I used standard GPS correlation not the reverse one (which I never used as it seems to work on tags vs. location names).
For loading there are no options at all, but the activated map was "Google Maps" at that time. With "Marble" (both "Atlas" and OSM) activated loading of the 185k waypoint file takes about 7s, de- and re-activating the tracks has no delay at all. So the described problem only occurs in conjunction with Google Maps (any map mode).

Comment 7 caulier.gilles 2017-09-03 10:19:26 UTC

Thanks to investigate.

When i talk about 5.7.0, i want mean to use the Linux universal AppImage bundle that we provide, not the distro based package.

AppImage is a single executable which have all needs embedded to run digiKam. It's perfect to check if a problem occurs or not without to install anything.

Files are there : 

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

Comment 8 Quincy 2017-09-03 11:15:07 UTC

Ahh cool, never seen that.
Regarding the bug: Behaves the same as with my "old" 5.5.0 version.

Comment 9 Maik Qualmann 2017-09-03 19:23:49 UTC

Can you provide a large GPX file? I have here one from my OSMtracker with 17500 points. Re-enable tracks does not take a second. Yes, Marble feels quicker.

Maik

Comment 10 Maik Qualmann 2017-09-06 18:12:19 UTC

Git commit 58ae8c0758e45e3f4f02a0713fd0893d5d29a904 by Maik Qualmann.
Committed on 06/09/2017 at 18:11.
Pushed by mqualmann into branch 'master'.

do not remove the track from the map when points are added

M  +1    -1    data/geolocation/geoiface/backend-googlemaps-js.js

https://commits.kde.org/digikam/58ae8c0758e45e3f4f02a0713fd0893d5d29a904

Comment 11 Maik Qualmann 2017-09-06 18:18:32 UTC

Thanks for the large GPX file on private e-mail. The loading time and the reactivation are now the same. I need 4.5 seconds for this GPX file. I do not close the bug yet, because I want to test whether the change has side effects.

Maik

Comment 12 Maik Qualmann 2017-11-20 21:13:28 UTC

I close the bug now. The speed is also limited by JavaScript.

Maik