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[1000000] duration= 21.848986999999997 ms. testAddLines[1000000] duration= 2883.4139689999997 ms. testAddQuads[1000000] duration= 11663.965977 ms. testAddCubics[1000000] duration= 26407.056027 ms. testAddMoveAndCloses[1000000] duration= 3348.6948319999997 ms. ... With patch applied: - Test(Path2D.Double[0]) --- testAddMoves[1000000] duration= 19.43655 ms. testAddLines[1000000] duration= 61.026067999999995 ms. testAddQuads[1000000] duration= 96.781376 ms. testAddCubics[1000000] duration= 128.759678 ms. testAddMoveAndCloses[1000000] duration= 81.86097099999999 ms. ... PS: I have not yet created the bug so the bugid is TODO in the test. Some comments below: 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 really see paths > that large other than via a test case? > Yes, my spiral test is insane ! but it may happen sometimes in GIS to have huge polygons ~ 300 000 segments. > > I think I'm good with the proposed fix, though. RAM sizes have also > changed dramatically since 1998... ;) > thanks. > > And trim() couldn't hurt. > No yet implemented; maybe at the next iteration or finally not necessary ? > > Another option for growable arrays that can deal with scalability is a > chain of arrays rather than a single growing array. It can get more > complicated to do the bookkeeping, but you can find a decent value of how > many entries can hide the incremental growth without having to deal with > the overhead of: > > - GC'ing the previous array > - needing 2x the storage for the N-1 and Nth arrays > - copying the data constantly from array i to i+1 > That's a good idea to keep in mind: it would be great to have such efficient growable array for primitive types in Arrays 2.0 ? Maybe the JVM could implement such "magic" undercover. Laurent
