Jim, just a reminder on my last patch waiting for review.
Meanwhile I improved a bit the array cleanup in the RLE case and got some gains: Test Threads Ops Med Pct95 Avg StdDev Min Max TotalOps CircleTests.ser 1 170 61.993 62.304 62.018 0.159 61.687 62.667 170 *EllipseTests-fill-false.ser * *1* *42* *248.594* *248.88* *248.65* *0.156* *248.435* *249.151* *42* *EllipseTests-fill-true.ser * *1* *27* *386.145* *386.453* *386.164* *0.243* *385.776* *387.088* *27* dc_boulder_2013-13-30-06-13-17.ser 1 117 90.063 90.623 90.106 0.255 89.682 91.224 117 dc_boulder_2013-13-30-06-13-20.ser 1 216 48.073 48.514 48.108 0.241 47.622 48.864 216 dc_shp_alllayers_2013-00-30-07-00-43.ser 1 265 39.533 39.851 39.466 0.257 39.054 40.075 265 dc_shp_alllayers_2013-00-30-07-00-47.ser 1 25 775.522 776.642 775.337 1.155 773.359 778.698 25 dc_spearfish_2013-11-30-06-11-15.ser 1 821 12.758 12.875 12.762 0.066 12.641 13.03 821 dc_spearfish_2013-11-30-06-11-19.ser 1 1629 6.425 6.517 6.441 0.035 6.4 6.609 1629 dc_topp:states_2013-11-30-06-11-06.ser 1 861 12.145 12.267 12.14 0.078 11.992 12.363 861 dc_topp:states_2013-11-30-06-11-07.ser 1 1372 7.663 7.722 7.653 0.045 7.467 7.807 1372 test_z_625k.ser 1 68 153.784 154.339 153.715 0.453 152.633 154.984 68 1. Do you prefer I send you another webrev including my last changes ? 2. I will be busy in november so I would like to anticipate Marlin integration into jdk9 forest: Integration Due: 2015-11-27 What is the plan according to you ? Could you merge gr forrest with latest jdk9 forrest ? Do you need me to perform some cleanup (system properties, code formatting like modifiers ...) before pushing marlin into jdk9 ? Should we refactor the array cache asap ? or it can be done after the first integration. Cheers, Laurent 2015-10-19 16:06 GMT+02:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Hi Jim, > > Here is the new webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-s4.2/ > > I added the OffHeapArray class used by Renderer and now by MarlinCache to > store rowAAChunk data. > Moreover I performed other small optimizations (heuristics, > Renderer.addLine() split in 2 methods) and many benchmarks to tune the new > approach. > > Could you review that patch, please ? > > Here are my last results: > Test Threads Ops Med Pct95 Avg StdDev Min Max TotalOps *CircleTests.ser * > *1* *172* *61.064* *61.311* *61.079* *0.131* *60.823* *61.67* *172* > *EllipseTests-fill-false.ser > * *1* *37* *278.548* *278.757* *278.557* *0.112* *278.362* *278.868* *37* > *EllipseTests-fill-true.ser > * *1* *25* *436.323* *436.866* *436.403* *0.27* *436.026* *437.318* *25* > dc_boulder_2013-13-30-06-13-17.ser > 1 114 91.316 91.75 91.355 0.279 90.803 92.505 114 > dc_boulder_2013-13-30-06-13-20.ser > 1 219 47.84 48.182 47.854 0.175 47.498 48.783 219 > dc_shp_alllayers_2013-00-30-07-00-43.ser > 1 265 39.432 39.61 39.433 0.108 39.21 40.052 265 > dc_shp_alllayers_2013-00-30-07-00-47.ser > 1 25 769.704 771.488 769.849 1.096 767.903 772.967 25 > dc_spearfish_2013-11-30-06-11-15.ser > 1 820 12.766 13.028 12.798 0.128 12.583 13.232 820 > dc_spearfish_2013-11-30-06-11-19.ser > 1 1637 6.413 6.613 6.438 0.067 6.375 6.777 1637 > dc_topp:states_2013-11-30-06-11-06.ser > 1 869 12.059 12.13 12.063 0.038 11.983 12.26 869 > dc_topp:states_2013-11-30-06-11-07.ser > 1 1421 7.391 7.453 7.392 0.023 7.329 7.52 1421 test_z_625k.ser 1 68 > 152.821 153.589 152.862 0.358 152.135 153.775 68 > > These are great results! And they are much easier to read with the tables >> (which seem to get lost in my reply, oops!). >> > > Thanks. > > >> If it is just the dashing results I can believe that as Ductus does a >> pretty good job of minimizing the number of segments in its stroked output >> paths. The losses are pretty small in that case so we are getting pretty >> close to being able to deprecate Ductus at some point which would be >> awesome (still a bit of reliability testing "in the wild" before we can >> actually switch full time, though)... >> > > As I mentioned few month ago, the Stroker can be improved to reduce the > number of generated segments related to caps & miter joins ie ignore > collinear edges. Moreover, it can be notably worth for dashed polygons > (many caps) or very complex polylines (many joins). > > Thanks for your time, > Laurent > -- -- Laurent Bourgès
