Hi Jim, >> I will now try being more opened minded to your valuable comments to >> improve code maintainability without sacrifying too much the performance >> level. > > It's a philosophy, not a hard requirement. And it is more important in a large project, especially Open Source where you get new people working on things all the time. > > In the short term, with just you working on the code, some concepts are much more manageable. Since you seem to be the only one putting forth any effort right now I have to balance disrupting the practices and philosophies that you are more comfortable with since they would make you more productive and the future of what happens when you achieve your objectives and the code awaits a new champion. Please don't ever let it progress to the point where you are too frustrated with some of the suggestions I am proposing that you want to walk away from the work, though. In the long run, having the improvements you are making in the code will be considerably more important than the amount of up-take time for future efforts. On the other hand, I do think that the best code bases I've seen in the past have been very concise to read and learn and understand and have had almost no quirky side effects outside of the advertised APIs. It's more of a mindset to care about code simplicity as you care about efficiency so both get designed in as you go.
That seems a good philosophy: I will stay focused on performance and you on readability / maintainability. Moreover your java2d experience is very important to me as you have the global overview on the complete pipelines (native, java fx, AA or not). As you know the java2d contributors, could you invite / motivate some of them to join this project ? I hope our collaboration will be successfull if we manage to stabilize Marlin code soon (minor algorithmic changes) and push it into jdk9 repo. Next we could work on RnD = more complex algorithmic improvements ... Anyway it is very important to release Marlin to JDK users as soon as we can. >> If you are now OK, can I push the patch including the 2 syntax fixes ? >> So I need to create a new bug id (to be able to push the changeset) ... > > > Definitely. Ok I will merge, build, test and push it today. > >> Should I wait you merge gr repo with latest jdk changes ? > > D'oh! I'll take care of that right away. Thanks. > >> As you wonder if initial arrays are still necessary, I will run tonight >> some benchmarks with initial arrays = [0]. > > > "arrays = [0]" - is that arrays set to bucket 0 sizes? That would be my guess as to how to proceed. Exactly: I changed MarlinConst.INITIAL_ARRAY... to 0. So initial arrays were created with size 0 or 1 that forced using array caches. I kept marlin statistics that indicate lots of cached arrays with usage counts. I will push them on cr.openjdk... However, I did not modify the OffHeap buffer size storing edge data = 128k. This edge array is the most critical and I use Unsafe instead of array cache to store both int/float values. I am sure it would have a big performance impact if downsized. I think it explains the difference with my first and last tests: 30% vs 5%. I will run benchmarks with offheap initial size = 10. >> I think the 30% overhead was a long time ago and should be less (dirty >> cache). However the cache code represents some overhead = get/grow/put + >> more resizing (copy) than initial arrays.... > > > I would think that starting out with bucket 0 sizes would reduce the frequency of resizing, no? Right. In this test, arrays are growing using bucket sizes. Bucket 0: size=4096 (16k) Bucket 1: size=16384 (64k) I tuned better initial arrays: smaller or larger than 4k = overhead for smaller arrays and more resizing for larger initial arrays. PS: I will also run benchmarks with smaller heap = 256mb instead of 2gb. It will evaluate the GC overhead with/without initial arrays. Laurent
