Re: Many changes in layers and markers

[Jiří Techet <techet gmail com>]

On Fri, Feb 11, 2011 at 05:07, Robert Park <rbpark exolucere ca> wrote:
> 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.

See https://bugzilla.gnome.org/show_bug.cgi?id=642086

>
> 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.

The construction itself should be reasonably fast as all the
construction is performed in C code and python bindings just return
the constructed object.

> _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.

Now if I created ChamplainMarker inside the layer, what marker should
I create? ChamplainLabel, ChamplainPoint or ChamplainCustomMarker? The
point is that any CamplainMarker can be a node of a layer and the
layer shouldn't prefer any specific marker.

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

So I'll fix the incredibly slow point addition to MarkerLayer but I'll
probably leave the point addition as it is unless you convince me this
causes huge performance penalty.

Jiri