[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)

[Andrea Aime]

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

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