Label polygon takes excessive time

[woodbri]

I have a world countries polygon shapefile and it displays in about 1 second using AGG renderer. If I add a label, then the render time for the layer increases to about 50 seconds. This is the time to render the layer only not process the label cache.

I have attached a tarball with the data and the mapfile. Here is a url on my server with the labels turned on: ​http://mt2.imaptools.com/cgi-bin/mapserv-5.4?map=%2Fu%2Fdata%2Fworld%2Fworld.map&layers=all&map_imagetype=agg&mode=map&mapext=-35997355.21934356+-19473536.007671427+18792705.280656442+23575797.242328573&imgext=-35997355.21934356+-19473536.007671427+18792705.280656442+23575797.242328573&map_size=700+550&imgx=350&imgy=275&imgxy=700+550

I loaded the data into postGIS and ran isvalid() which reports a lot of self-intersections on about half the objects. This has never been a problem for mapserver in the past and may not be the issue with this, but I seem to remember that we recently change the polygon label point generation scheme and this may be problematic with this shapefile.

[woodbri]

Argh, The file (43MB is to large to upload) so you can get it from: ​http://imaptools.com/downloads/world.tbz

All you need to do in the mapfile is re-point the paths to the directory you untar it into, and to see the speed difference just comment out LABELITEM "NAME" and it will render fast.

[pramsey]

Remove isOuterRing patch from getPolygonCenterOfGravity

[pramsey]

The problem is too many calls to msPointInPolygon, driven by the isOuterRing test in getPolygonCenterOfGravity. And it looks like those can be avoided by simply not doing them: getPolygonCenterOfGravity says it only uses the biggest ring, and the biggest ring will always be larger than the interior rings. Running the calculation on all the rings is cheaper than figuring out which rings not to run the calculation on.

[pramsey]

And, and that file is *way* too detailed for that scale. :)

[jmckenna]

wow i agree, no wonder it's choking on this file.

[pramsey]

Nothing like a degenerate case to expose an issue though. That 30:1 time difference makes me sit up and take notice.

[sdlime]

There was a reason that test was there I thought, perhaps dealing with holes? Simpler is better though.

Steve

[pramsey]

I can easily see you thinking "I only want outer rings, so I'll test away the inner ones". It's not immediately obvious that testing away the inner ones is far more expensive that running the calculation on them.

[sdlime]

For some reason I recall Thomas running into a problem where coordinate order flipped the sign of the area computation and this worked around that. I'll dig into my mail archive to make sure...

Steve

[sdlime]

Fixed in 5.4 (r9131) and trunk (r9132). Closing...

Steve