Hi Laurent,
I haven't looked at the changes in depth yet, but I wanted to echo my comments
on the AAShapePipe thread - make sure you do benchmark testing on multiple
platforms and double check if caching small objets actually helps anything
(otherwise it is unnecessary code complexity and possibly a detrimental change
given that Hotspot optimizes small object allocation so much)...
...jim
On 4/1/2013 2:20 PM, Laurent Bourgès wrote:
Andra & Jim,
Here is the current status of my patch alpha version:
http://jmmc.fr/~bourgesl/share/java2d-pisces/
There is still a lot to be done: clean-up, stats, pisces class instance
recycling (renderer, stroker ...) and of course sizing correctly initial arrays
(dirty or clean) in the RendererContext (thread local storage).
For performance reasons, I am using now RendererContext members first (cache
for rowAARLE for example) before using ArrayCaches (dynamic arrays).
I provided the patch as zip file and few benchmark using Andrea's MapBench
(Xmx128m):
- OpenJDK 8 PATCHED:
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 3687 ms
2 threads and 20 loops per thread, time: 3693 ms
4 threads and 20 loops per thread, time: 6849 ms
Loading drawing commands from file:
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
1 threads and 20 loops per thread, time: 27266 ms
2 threads and 20 loops per thread, time: 33628 ms
4 threads and 20 loops per thread, time: 61577 ms
- OpenJDK 8 REFERENCE:
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 3982 ms
2 threads and 20 loops per thread, time: 4852 ms
4 threads and 20 loops per thread, time: 8842 ms
Loading drawing commands from file:
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
1 threads and 20 loops per thread, time: 55889 ms
2 threads and 20 loops per thread, time: 77691 ms
4 threads and 20 loops per thread, time: 141981 ms
- Oracle JDK8 DUCTUS:
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 1894 ms
2 threads and 20 loops per thread, time: 3905 ms
4 threads and 20 loops per thread, time: 7485 ms
Loading drawing commands from file:
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
1 threads and 20 loops per thread, time: 20911 ms
2 threads and 20 loops per thread, time: 39297 ms
4 threads and 20 loops per thread, time: 103392 ms
As you can see, patched openJdk8 performs better and it is very noticeable on
big drawings (dc_shp_alllayers_2013-00-30-07-00-47.ser) and better than ductus
with 2 threads !!
Laurent
2013/3/30 Andrea Aime <andrea.a...@geo-solutions.it
<mailto:andrea.a...@geo-solutions.it>>
On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès <bourges.laur...@gmail.com
<mailto:bourges.laur...@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:
* ShapeDumpingGraphics2D, a Graphics2D wrapper writing on disk all
draw(Shape) and
fill(Shape) commands issued to it
* A bunch of *.ser files, that are the serialized drawing command sequences
* A bunch of *.png files, which are the rendered versions of the .ser files
(for reference)
* MapDisplay, which reads all *.ser files from a directory and displays
them in JFrame and
generates the .png files as well
* MapBench, which reads all *.ser files from a directory and repeatedly
paints them in a loop
with a growing number of threads
* Two txt files with the timings of the benchmarks on my machine for Oracle
JDK 7 and
OpenJDK 7, here is an example comparison:
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
-------------------------------------------------------
