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

[Larry Shaffer]

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;