Jim, Andrea,
I updated MapBench to provide test statistics (avg, median, stddev, rms,
med + stddev, min, max) and CSV output (tab separator):
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/
<http://jmmc.fr/%7Ebourgesl/share/java2d-pisces/MapBench/>
Here are the results (OpenJDK8 Ref vs Patched):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_det.log
http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_det.log
test threads ops Tavg Tmed stdDev rms Med+Stddev
min max
boulder_17 1 20 180,22% 181,08% 1186,01%
181,17% 185,92%
176,35% 170,36%
boulder_17 2 20 183,15% 183,80% 162,68%
183,78% 183,17%
174,01% 169,89%
boulder_17 4 20 216,62% 218,03% 349,31%
218,87% 226,68%
172,15% 167,54%
shp_alllayers_47 1 20 243,90% 244,86% 537,92%
244,87% 246,39%
240,64% 231,00%
shp_alllayers_47 2 20 286,42% 287,07% 294,87%
287,07% 287,23%
277,19% 272,23%
shp_alllayers_47 4 20 303,08% 302,15% 168,19%
301,90% 295,90%
462,70% 282,41%
PATCH:
test threads ops Tavg Tmed stdDev rms Med+Stddev
min max
boulder_17 1 20 110,196 109,244 0,529 109,246
109,773 108,197
129,327
boulder_17 2 40 127,916 127,363 3,899 127,423
131,262 125,262
151,561
boulder_17 4 80 213,085 212,268 14,988 212,796
227,256 155,512
334,407
shp_alllayers_47 1 20 1139,452 1134,858 5,971
1134,873 1140,829
1125,859 1235,746
shp_alllayers_47 2 40 1306,889 1304,598 28,157
1304,902
1332,755 1280,49 1420,351
shp_alllayers_47 4 80 2296,487 2303,81 112,816
2306,57 2416,626
1390,31 2631,455
REF:
test threads ops Tavg Tmed stdDev rms Med+Stddev
min max
boulder_17 1 20 198,591 197,816 6,274 197,916
204,091 190,805
220,319
boulder_17 2 40 234,272 234,09 6,343 234,176
240,433 217,967
257,485
boulder_17 4 80 461,579 462,8 52,354 465,751
515,153 267,712
560,254
shp_alllayers_47 1 20 2779,133 2778,823 32,119
2779,009
2810,943 2709,285 2854,557
shp_alllayers_47 2 40 3743,255 3745,111 83,027
3746,031
3828,138 3549,364 3866,612
shp_alllayers_47 4 80 6960,23 6960,948 189,75
6963,533 7150,698
6432,945 7431,541
Linux 64 server vm
JVM: -Xms128m -Xmx128m (low mem)
Laurent
2013/4/14 Andrea Aime <andrea.a...@geo-solutions.it
<mailto:andrea.a...@geo-solutions.it>>
On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourgès
<bourges.laur...@gmail.com <mailto:bourges.laur...@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/
<http://jmmc.fr/%7Ebourgesl/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
<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
-------------------------------------------------------
