Re: Many changes in layers and markers

[Russell Strong <russell strong id au>]

On Fri, 2011-02-11 at 22:02 +0100, Jiří Techet wrote:
> 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

or how about .append_points which would take a list/array of points.
This may be an easy workaround for doing multiple redraws.  Another way
multiple redraws could be handled would be to set up an idle callback
that would do the redraw after any points were added.  

> > 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
> _______________________________________________
> libchamplain-list mailing list
> libchamplain-list gnome org
> http://mail.gnome.org/mailman/listinfo/libchamplain-list