Re: Many changes in layers and markers

[Robert Park <rbpark exolucere ca>]

I've found a performance regression that is... grotesque beyond belief.

My application includes a 44kb GPX file for demonstration purposes.
Before the API breakage, I could load and display that file in 0.02
seconds. Now it takes 2.5s, which is 125x slower. More importantly, I
have a 4.4MB GPX file that I use for benchmarking, and it used to load
in 5.79s. I don't know how long it takes to load now, because I gave
up waiting for it after several minutes. To give you some frame of
reference here, my very first GPX parser that I naively wrote with the
pure-python minidom XML parser took 19 minutes to load this file.
Switching to the fast C-based expat library brought that down into the
neighborhood of 12 seconds, and then various optimizations since then
have whittled it down to just 5.79 seconds. I'll do some profiling
tonight and try to figure out what precisely is the culprit here, but
I have a few suspects.

First of all, if the MarkerLayer's path is visible, that destroys
EVERYTHING. if I comment out the line "layer.set_path_visible(True)",
that speeds up the smaller file from 2.5s to 0.08 seconds. However,
0.08s is still 4x slower than before. The 4.4MB file takes 366.5s to
load while the path is invisible, a slowdown of 63x.

The other thing is that my GPX parser used to call
ChamplainPolygon.append_point directly, and then keep the returned
ChamplainPoint in a dictionary. If I'm understanding the new API
correctly, I have to construct ChamplainMarkers myself, and then
append those, instead of just passing floats directly into the
append_point method. Unfortunately, python is slow! Constructing
ChamplainMarkers can't ever be as fast as passing in floats directly.
_PLEASE_ bring back something like
ChamplainMarkerLayer.append_point(float lat, float lon) that does the
construction of ChamplainMarkers itself in fast C code. I'm not sure
if the new ChamplainMarker has much more overhead than the old
ChamplainPoint did, but this change in the API has created a new,
ugly, and slow method that's called from right in the heart of my
tightest inner loop inside my once-fast GPX parser.

So, please fix up the incredi-slow MarkerLayer path rendering, and
bring back append_point. Thanks for listening ;-)