arne-bdt commented on PR #1918: URL: https://github.com/apache/jena/pull/1918#issuecomment-1606246332
I have tried to remedy all your findings. Additionally: - Added some missing Javadoc descriptions for parameters and return values. - Tweaked the PatternClassifier a bit by testing `Triple#isConcrete` first. - I found out that the RoaringBitmap BatchIterator is not that fast in the use cases covered by the benchmarks. So I replaced the implementation in RoaringBitmapTripleIterator. I have no plans for further changes. I just ran the JMH benchmarks for more graphs and iterations (which often runs for many hours) and came across a few anomalies. That´s why I made changes to PatternClassifier and RoaringBitmapTripleIterator. I will still post the results here and highlight any remaining "anomalies". For example, org.apache.jena.mem.graph.TestGraphContainsTriple#graphContains almost always shows better performance of GraphMem2Fast than GraphMem2Legacy. With "bsbm-5m.nt.gz", however, GraphMem2Fast is clearly slower. I tried unsuccessfully to find the cause with the profiler. According to the profiler, GraphMem2Fast is faster. I also tried to adjust the implementations: - used the normal equals in containsKey in the FastArrayBunches - set the maximum size of the FastArrayBunches to 8 elements (GraphMem2Legacy has 9) - tried variants from HashCommonBase and the Java HashMap in FastHashBase for calculating the position from the hash code. --> all without success. (so I reverted these experiments) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
