Very long time of "Remove all before" operation
PROBLEM:
When I`m trying to use "Remove all before" option in examined point of recorder track, it took incredible long time to do that. Here are my tests:
Manually draw track consists of 10 points
Tests:
1. "Remove all before" the 2nd point ( one point + one line to be deleted) - 26.5 seconds
2. "Remove all before" the 3rd point ( two points + two lines to be deleted) - 1:34
3. "Remove all before" the 4th point ( two points + two lines to be deleted) - 1:09
4. "Remove all before" the 4th point ( same as above, but with much shorter distances) - 1:24
When testing on 10000 points tracks - I must kill the Locus process, because waiting time is so long (possibly days:)).
CONCLUSIONS:
1. There should be a "Cancel" button for this operation (to avoid killing the process if user wants to cancel the operation.
2. It looks like the distance of the lines don`t matter.
3. Strangely, test 3 took less time than test 2, which possibly means that the time is related to processor`s load.
4. Bear in mind, that I have HUGE tracks and points collection in my phone, and its is old model Desire Z. BUT, when I`m splitting the same track it takes about 20 second to do that. Even the 10000 points tracks are split really quickly. This is telling me that the algorithms are different here. The splitting one is much more efficient.
Please look also at "Remove all after", because I believe it is also affected by the same factors.
The same problem 
Any acknowledgement?
Any acknowledgement?
there is generally one major problem
- too many tracks, mainly points
- slow SQLite performance of Android SQLite library
- missing indexes in table on points
So result is very slow queries in you case. Why you btw. need to have all tracks in Locus? Why you just do not export them to some GPX files for example?
there is generally one major problem
- too many tracks, mainly points
- slow SQLite performance of Android SQLite library
- missing indexes in table on points
So result is very slow queries in you case. Why you btw. need to have all tracks in Locus? Why you just do not export them to some GPX files for example?
These problems ... I understand, but why Splitting a tracks is so quick? Shouldn`t the problems you mentioned also affect a speed of Splitting a track?
I like to have originals. I`m automatically exporting to .kmz, but I like to have originals and be able to quickly load/show any track from a past. For example when I`m going to the same place I was year before, I can load a track from that place. I don`t trust exporting and then reimporting, I`m always afraid I will lose some data/details during this process. Another reason is: this is my collection of tracks, I like to see when their quantity is increasing constantly:)
These problems ... I understand, but why Splitting a tracks is so quick? Shouldn`t the problems you mentioned also affect a speed of Splitting a track?
I like to have originals. I`m automatically exporting to .kmz, but I like to have originals and be able to quickly load/show any track from a past. For example when I`m going to the same place I was year before, I can load a track from that place. I don`t trust exporting and then reimporting, I`m always afraid I will lose some data/details during this process. Another reason is: this is my collection of tracks, I like to see when their quantity is increasing constantly:)
oki, I rewrote whole part that delete points from track database. Now it will be faster but even in this case, expect in your database times more then 10s. even for single point.
I have for testing one database (120MB), where deleting 1 point took around 5s, 1000 points around 15s, funny ... so you`ll see
Btw. with my track database around 20MB, 1 points is < 1s, 1000 points around 3s ...
oki, I rewrote whole part that delete points from track database. Now it will be faster but even in this case, expect in your database times more then 10s. even for single point.
I have for testing one database (120MB), where deleting 1 point took around 5s, 1000 points around 15s, funny ... so you`ll see
Btw. with my track database around 20MB, 1 points is < 1s, 1000 points around 3s ...
That`s fine. It also took 20 seconds to split the tracks, its not a problem. Thanks.
BTW, when are you releasing next version of Locus?
That`s fine. It also took 20 seconds to split the tracks, its not a problem. Thanks.
BTW, when are you releasing next version of Locus?
fine ...
new testing versions are published on forum. Final release will be probably at start of next week ..
fine ...
new testing versions are published on forum. Final release will be probably at start of next week ..
Ok. I will use this place and time to ask you. When I was using test versions long time ago, I remember my biggest problem was that they were not overwriting the Locus Pro (they were treated as a separate application). So I had to jump between two Locuses ( which I can`t accept ). Is that still a case? Or was I doing something wrong? If its still a case, why and can something be done with it? If its a separate application I need to configure it all over again.
Ok. I will use this place and time to ask you. When I was using test versions long time ago, I remember my biggest problem was that they were not overwriting the Locus Pro (they were treated as a separate application). So I had to jump between two Locuses ( which I can`t accept ). Is that still a case? Or was I doing something wrong? If its still a case, why and can something be done with it? If its a separate application I need to configure it all over again.
yes it`s same as you wrote. Some settings are anyway shared (visible points/tracks, top/right panel, add quick point), rest of them are separate as they use common android preferences system ...
yes it`s same as you wrote. Some settings are anyway shared (visible points/tracks, top/right panel, add quick point), rest of them are separate as they use common android preferences system ...
Its a shame that a new settings export feature doesn`t work yet.
Its a shame that a new settings export feature doesn`t work yet.
Replies have been locked on this page!