[OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

[Laurent Bourgès]

Jim & phil,

The initial objective of my patch concerns the grow algorithm to use 1/8th
of the array size instead of the fixed EXPAND_MAX (=500) !

For huge paths, it avoids a lot of growing passes and is a lot faster (see
Path2DGrow test: 2s vs 56s).

However, it wastes more memory (overflow or OOME can occur) so arrays
should be trimmed manually or automatically when calling some methods like
getPathIterator ().
It is not possible to infer what is the Path2D usage pattern... and when a
growable array should be resized down (too much waste threshold ?)

I think the bug you created does not mention the problem on the grow
algorithm at all. That fix could be backported to 1.8 except new trimToSize
() methods.

Le 21 avr. 2015 00:11, "Jim Graham" <james.graham at oracle.com> a écrit :
>
> To answer my own question - since we already have a changeset with just
the new trim-on-copy stuff that is backwards compatible and since this
change only adds the new trim method and some overflow protection, we can
just go with the previous fix if we decide to backport things.  The added
value of the new overflow protection is not enough to further split this
particular change down...

I disagree: the new grow algorithm is a lot better for huge paths and is an
important performance fix that should be backported to 1.8 too.

Should I update the bug description or create a new one like 'Path2d
needRoom very slow for huge paths' ?

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150421/255161d0/attachment.html>