lucasvr opened a new pull request, #1800: URL: https://github.com/apache/jena/pull/1800
CPU profiling of a brand new installation of jena-fuseki shows that ~75% of the time spent by `s-put` (when ingesting Turtle tuples via SPARQL) relates to the execution of `ByteBufferLib.bbcopy2()` -- often as part of B+tree operations such as `BPTreeNode.internalDelete()`. `bbcopy2()` and `bbcopy1()` perform data copy from a source ByteBuffer to a destination ByteBuffer by reading/writing one byte at a time, which is not very efficient. In addition, `bbcopy1()` makes a poor use of data cache prefetches, as it iterates the ByteBuffers in reverse order. This commit replaces the implementation of these two functions by one that reads the input data in bulk mode into a dynamically allocated byte array and then writes its contents to the destination buffer using a bulk `put()` operation. The same approach is used to improve the performance of another bottleneck in `RecordBuffer::compare()`. The speedup gains introduced by these code changes are consistent regardless of the number of triples being ingested into Jena: Input file: 1.2GB with 1.75M triples Original ingestion time: 544 secs After changes to bbcopy: 454 secs (1.19x speedup) After changes to bbcopy and compare(): 388 secs (1.40x speedup) Input file: 21MB with 154k triples Original ingestion time: 7.4 secs After changes to bbcopy: 6.0 secs (1.24x speedup) After changes to bbcopy and compare(): 5.23 secs (1.43x speedup) -- 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]
