[Kde-imaging] [kipiplugins] [Bug 342427] New: Load and "Show tracks on Map" timing issues with large GPX files

[Quincy]

https://bugs.kde.org/show_bug.cgi?id=342427

            Bug ID: 342427
           Summary: Load and "Show tracks on Map" timing issues with large
                    GPX files
           Product: kipiplugins
           Version: 4.4.0
          Platform: Gentoo Packages
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: GPSSync
          Assignee: kde-imaging at kde.org
          Reporter: bbc.quincy at gmx.de

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

-- 
You are receiving this mail because:
You are the assignee for the bug.