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>
> On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès <
> 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
>
> -------------------------------------------------------
>
