[OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements (original) (raw)

Andrea Aime andrea.aime at geo-solutions.it
Sun Apr 14 15:37:07 UTC 2013

On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourgès <bourges.laurent at gmail.com>wrote:

Dear Java2D members,

Could someone review the following webrev concerning Java2D Pisces to enhance its performance and reduce its memory footprint (RendererContext stored in thread local or concurrent queue): http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ FYI I fixed file headers in this patch and signed my OCA 3 weeks ago. Remaining work: - cleanup (comments ...) - statistics to perform auto-tuning - cache / memory cleanup (SoftReference ?): use hints or System properties to adapt it to use cases - another problem: fix clipping performance in Dasher / Stroker for segments out of bounds Could somebody support me ? ie help me working on these tasks or just to discuss on Pisces algorithm / implementation ?

Hi, I would like to express my support for this patch. Given that micro-benchmarks have already been run, I took the patch for a spin in a large, real world benchmark instead, the OSGeo WMS Shootout 2010 benchmark, for which you can see the results here: http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010

The presentation is long, but suffice it to say all Java based implementations took quite the beating due to the poor scalability of Ductus with antialiased rendering of vector data (for an executive summary just look at slide 27 and slide 66, where GeoServer, Oracle MapViewer and Constellation SDI were the Java based ones)

I took the same tests and run them again on my machine (different hardware than the tests, don't try to compare the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a checkout a couple of weeks old) and the same, but with Laurent's patches applied. Here are the results, throughput (in maps generated per second) with the load generator (JMeter) going up from one client to 64 concurrent clients:

Threads JDK 1.7.0_17 OpenJDK 8, vanilla OpenJDK 8 + pisces renderer improvements Pisces renderer performance gain, % 1 13,97 12,43 13,03 4,75% 2 22,08 20,60 20,77 0,81% 4 34,36 33,15 33,36 0,62% 8 39,39 40,51 41,71 2,96% 16 40,61 44,57 46,98 5,39% 32 41,41 44,73 48,16 7,66% 64 37,09 42,19 45,28 7,32%

Well, first of all, congratulations to the JDK developers, don't know what changed in JDK 8, but GeoServer seems to like it quite a bit :-). That said, Laurent's patch also gives a visible boost, especially when several concurrent clients are asking for the maps.

Mind, as I said, this is no micro-benchmark, it is a real application loading doing a lot of I/O (from the operating system file cache), other processing before the data reaches the rendering pipeline, and then has to PNG encode the output BufferedImage (PNG encoding being rather expensive), so getting this speedup from just a change in the rendering pipeline is significant.

Long story short... personally I'd be very happy if this patch was going to be integrated in Java 8 :-)

Cheers Andrea

--

GeoServer training in Milan, 6th & 7th June 2013! Visit http://geoserver.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

More information about the core-libs-dev mailing list