[Qgis-developer] Remaining work to get rid of old labeling?

Sun Nov 18 14:53:13 PST 2012

>> Thank you for these interesting results. You are right, we first need to
>> understand where the time is spent.
>> Did you make sure the font settings are the same for new / old symbology in
>> the comparison? I see that the buffer is enabled by default in the new
>> labelling and disabled by default in the old one. Also, buffer unit is mm in
>> new engine and point in the old one.
>
> I double-checked, and there were no buffer settings turned on for
> either engine. The font settings were also the same (default app/Qt
> font, not styled, same point size).
>
> I'm currently looking into setting up Valgrind and adding more
> embedded QTime debugging output. Also, going to recompile 1.8 with
> debug output so I can do a side-by-side comparison between master, to
> see if any recent code introduced is causing a performance issue.
>
>
> Anyone have an opinion about the following (previously posted)? ...

For the devs on Mac, setup XCode, and then use DTrace (Its under
Instruments?) to profile, there are ready made scripts to do the CPU
profiling...

>
> -------------------->8====
> About 5): Once the old engine's gui is gone, what about users who open
> a project still using the old labeling? Should the app just prompt
> them that there are affected layers and to re-label them using the new
> engine, or should there be a function/dialog added that offers to
> attempt to automatically port those layers over to the new engine?
>
> The latter might not be too hard since the old engine basically just
> labeled points; and, I believe, all of those old settings should port
> over to the new Offset settings. The only similar placement missing is
> how line layers were labeled in old engine is not present in new
> engine. The 'Horizontal' placement in new engine for line labels does
> not work the same, and does not support the quadrant/x/y offsets. I
> can add the proposed 'Midpoint' placement (see previously noted [1]
> list) which would essentially be identical to old engine, or better,
> add such functionality to the existing Horizontal placement.
>
> Then, auto-porting of old to new engine layers would be possible.
> Whether the old-to-new labels will look identical and be placed the
> same is another issue. Though, I don't think very much development
> effort should be expended on making them look exactly the same.
>
> ====8<----------------------------
>
>
> Regards,
>
> Larry
>
>> Regards,
>> Marco
>>
>> On 18.11.2012 05:56, Larry Shaffer wrote:
>>>
>>> Hi,
>>>
>>> On Sat, Nov 17, 2012 at 3:09 PM, Sandro Santilli <strk at keybit.net> wrote:
>>>>
>>>> On Fri, Nov 16, 2012 at 12:13:18PM -0700, Larry Shaffer wrote:
>>>>
>>>>> The new engine offers complex collision
>>>>> management, while the old one does not, which will always take up more
>>>>> cpu cycles. While I don't think the new engine will ever be as fast as
>>>>> a simpler one, a reasonable effort should be made to optimize it as
>>>>> much as possible before adding cool new features, like leader-line
>>>>> labels, that will again up the computational cost.
>>>>>
>>>>> Obviously the new engine could be faster, but is its current
>>>>> performance really a blocking issue for removing the old one?
>>>>
>>>> The new engine can work with collision detection removed, right ?
>>>> Would it be as fast as the old one in that case ?
>>>> Could that behavior be made the default, so that old users won't
>>>> notice any difference and new users won't be hit by performance
>>>> issues until opting for a better placement ?
>>>
>>> Unfortunately, it doesn't look that way. I ran some basic tests using
>>> QTime, like had already been set up for QgsPalLabeling, and came up
>>> with results pointing to a performance regression that probably needs
>>> addressed before the old engine is removed.
>>>
>>> Note: these manual tests were run against a point layer, which does
>>> not generate extra calculations for dynamic placements, like for line
>>> or polygon layers (i.e. these are the best case results for PAL, for
>>> comparison to old engine, not a cross-section of average use).
>>>
>>> Data: point layer with 10888 points (8 layers of 1361 features each,
>>> in test groups)
>>> CPU: Intel 64, i5
>>>
>>> OLD Engine draw:  1012 ms
>>> (this had nominal variance during testing)
>>>
>>> PAL Engine settings (not default, trying for best case):
>>> FALP, 1 cand. for point layers, show all labels
>>>
>>> Offset placement:
>>> PAL work:  1949 ms
>>> PAL draw:  2045 ms
>>>
>>> Around placement:
>>> PAL work:  1337 ms
>>> PAL draw:  1981 ms
>>>
>>> Data defined and pinned:
>>> PAL work:  1311 ms
>>> PAL draw:  1989 ms
>>>
>>> PAL Offset 3994 ms / OLD 1012 ms = 3.95x slower
>>> PAL Around 3318 ms / OLD 1012 ms = 3.28x slower
>>> PAL Data defined 3300 ms / OLD 1012 ms = 3.26x slower
>>>
>>> Elapsed times for PAL got worse as zooming out caused labels to
>>> overlap more. Final zoom out was reached when labels created a solid
>>> black interior of overlap.
>>>
>>> PAL Offset zoom out, full overlap:
>>> PAL work:  5377 ms
>>> PAL draw:  1981 ms
>>>
>>> PAL Data defined zoom out, full overlap:
>>> PAL work:  3752 ms
>>> PAL draw:  1993 ms
>>>
>>> PAL Offset with full extent, 50% overlap as individual layer (1/8):
>>> PAL work:  48 ms (x8 = 384)
>>> PAL draw:  280 ms (x8 = 2240 )
>>>
>>> Extrapolated from 1 layer to 8:
>>> PAL 2624 ms / OLD 1012 = 2.59x slower
>>> (PAL work still gets slower on zoom out, though less overlap checking)
>>>
>>> Back to using all 8 layers (10888 features) at once, with default
>>> engine settings...
>>>
>>> PAL Offset with collision management
>>> PAL work:  10065 ms  !
>>> PAL draw:  15 ms ... labels# 75 (10888 - collisions)
>>>
>>> PAL Around with collision management
>>> PAL work:  4100 ms
>>> PAL draw:  24 ms ... labels# 114 (10888 - collisions)
>>>
>>> PAL Data defined with collision management (Offset layer setting)
>>> PAL work:  1375 ms
>>> PAL draw:  14 ms ... labels# 77 (10888 - collisions)
>>> (i.e. no significant difference in work, compared to 'show all labels'
>>> set to on)
>>>
>>> Some conclusions to draw from these preliminary results:
>>>
>>> 1) Qt drawing time stays rather consistent. QgsPalLabeling's method
>>> (PAL lib doesn't actually draw) looks to be ~2x slower than old
>>> engine. Making the change to text-as-text output may help with this.
>>>
>>> 2) Regardless of the 'show all' labels setting for the engine,
>>> overlaps are still calculated even though it seems to make no sense
>>> (labels should basically be outputted to screen like old engine,
>>> yes?). This is even the case for x/y data defined labels. The overlap
>>> issue should be addressed.
>>>
>>> 3) PAL Offset placement has worse performance than Around. Seems like
>>> it should be closer to data defined results. It's code should be
>>> reviewed for optimization.
>>>
>>> 4) At 'best' configuration for comparison to old engine, PAL can be
>>> considered to be overall 2-4 times slower, depending upon overlap of
>>> labels due to zoom level. I think this is enough to warrant serious
>>> investigation into optimizations, before removing old engine.
>>>
>>> Regards,
>>>
>>> Larry
>>>
>>>> Of course it's still useful to improve the performance of collision
>>>> detection code but could be done with less pressure...
>>>>
>>>> --strk;
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>> --
>> Dr. Marco Hugentobler
>> Sourcepole -  Linux & Open Source Solutions
>> Weberstrasse 5, CH-8004 Zürich, Switzerland
>> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
>> Technical Advisor QGIS Project Steering Committee
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer