arne-bdt commented on PR #1918: URL: https://github.com/apache/jena/pull/1918#issuecomment-1608904299
I think you are right. It's just that I found that some iterators and streams were slower than my last PR for GraphMem iterators. Sometimes I might be chasing phantoms. But there were other benchmarks with consistent behaviour. So I decided to get to the bottom of it: - In my first attempt, I only used the SparseArraySpliterator. Now it seems worth splitting it into SparseArraySpliterator and SparseArraySubSpliterator, as I did with GraphMem. The same goes for ArraySpliterator. - the NestedIterator was a lame implementation. I replaced it with IteratorOfJenaSets. - for RoaringBitmapIterator, using BufferedIterator was a good choice for #hasNext and #next, but not for #forEachRemaining. So I changed the implementation. Some results in my benchmarks remain unclear to me: - TestGraphContainsTriple for concrete triples on GraphMem2Fast shows faster performance than GraphMem for most graphs, but for some graphs (e.g. EQ and BSBM 5) the benchmarks consistently show lower performance. - TestGraphFindAllWithForEachRemaining on GraphMem2Legacy proves faster than GraphMem for smaller graphs, but for larger graphs the benchmarks consistently show that GraphMem2Legacy is slightly slower. Due to their same inner structure, I would not expect hat. It might be an issue in the benchmarks but I am not sure. Apart from these points, I have not found anything else to worry about in the latest JMH benchmarks. I have attached some of the latest JMH benchmarks for the various use cases. I only used 20 iterations to get the results faster, but they should show what you can expect from which implementation for different use cases. [benchmark_results.zip](https://github.com/apache/jena/files/11878549/benchmark_results.zip) -- 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]
