Hello.
Is that a problem that with the new code we can get OOM earlier in some
cases? Should we take care of overflow more carefully now? It seems that
ArrayList.grow contains similar logic.
02.04.15 23:59, Jim Graham wrote:
All of your comments are spot on (modulo the confusion over
The patch as it is will make things much better, but it may be worth
doing it right as long as we are revisiting this algorithm and write
it to deal better with the OOME/integer overflow cases.
I looked at the ArrayList code and found a bit of voodoo there in the
overflow code which troubled
Andrea,
Great to have your point of view !
Is it public data ?
Is it possible to convert this particular shape file to a MapBench's
serialized command file (not simplified, please) ?
It would be helpful to have concrete but very complex shapes to perform
both renderer benchmarks (marlin,
On Fri, Apr 3, 2015 at 3:50 PM, Laurent Bourgès bourges.laur...@gmail.com
wrote:
Andrea,
Great to have your point of view !
Is it public data ?
I'm afraid not
Is it possible to convert this particular shape file to a MapBench's
serialized command file (not simplified, please) ?
Jim,
Here is the first webrev:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D_needRoom.0/
I created a test Path2DGrow that also gives some timings:
Without patch:
- Test(Path2D.Double[0]) ---
testAddMoves[100] duration= 21.8489867 ms.
testAddLines[100] duration=
On Fri, Apr 3, 2015 at 3:22 PM, Laurent Bourgès bourges.laur...@gmail.com
wrote:
All of your comments are spot on (modulo the confusion over Pisces/Marlin
vs Path2D). And you are right that 500 seems pretty lean to me. 800K path
segments seems to be a pretty large outlier, though, do we
Sergey,
2015-04-03 15:16 GMT+02:00 Sergey Bylokhov sergey.bylok...@oracle.com:
Hello.
Is that a problem that with the new code we can get OOM earlier in some
cases? Should we take care of overflow more carefully now? It seems that
ArrayList.grow contains similar logic.
I advocate I did not
