[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) (original) (raw)

Andrea Aime andrea.aime at geo-solutions.it
Sat Mar 30 19:23:40 UTC 2013

On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès <bourges.laurent at gmail.com>wrote:

- clipping issues (dasher, stroker) and spatial resolution (no cpu/memory waste)

I see, yes. Indeed in the GeoServer code we already work around some of those issues by clipping the geometries read from the database to the graphics2d viewport before giving them to the renderer, we had to do that both for performance issues and to avoid OOM errors when basic stroke with dasharray is used against a line that is many times longer than the current display area

I don't have anything ready, the existing code loads data from spatial

database, sets up styles from XML descriptions, turns each spatial db geomety in java shapes and so on. But I guess I could concoct something close enough. I'm writing some code to gather statistics about the shapes that are actually painted (scrolling over the path iterators) and then I'll try to make a randomized shape painter that gets close to those stats.

Great news ! I am waiting your test code to perform few benchmarks. I am using J2DBench but it does not perform such complex drawing (complex shapes ...) or multi threading tests (parallel drawings on buffered images)

Ok, I've created a "MapBench" by serializing shapes, strokes and fills from a real GeoServer instance to disk, and have them play in a simple multithreaded test harness. What you get in the output is not exactly the maps generated by GeoServer since we use a number of tricks to speed up rendering, including painting over multiple drawing surfaces (the serializer only handles one), also, some maps have text showing up because in order to pain "labels along a line" we actually turn the chars into shapes and place them along the line, but those labels that we can predict are "straight" are painted with drawGlyphVector so they won't show up (haven't built a serialization for that case).

Regardless, the test should be good enough to test both performance and scalability. Here is the package: http://demo.geo-solutions.it/share/mapbench.zip

It contains:

OpenJDK7: Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 3340 ms 2 threads and 20 loops per thread, time: 3688 ms 4 threads and 20 loops per thread, time: 4665 ms 8 threads and 20 loops per thread, time: 7343 ms

Oracle JDK 7: Warm up took 29516 ms Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 1754 ms 2 threads and 20 loops per thread, time: 2878 ms 4 threads and 20 loops per thread, time: 6792 ms 8 threads and 20 loops per thread, time: 14275 ms

As you can see ductus is significantly faster than pisces, but it has serious scalability issues, while pisces scales up a lot better.

The code has been put together in a haste, sorry for the lack of comments, hopefully it is simple enough that it's usable anyways.

Cheers Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime @geowolf Technical Lead

GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549

http://www.geo-solutions.it http://twitter.com/geosolutions_it

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130330/8553256b/attachment.html>

More information about the 2d-dev mailing list