Then it might make sense to make a new bug and target the existing patch
at it by just removing the new method signature...
...jim
On 4/20/15 11:56 PM, Laurent Bourgès wrote:
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" <[email protected]
<mailto:[email protected]>> 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
