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

[Andrea Aime]

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

-------------------------------------------------------