Optimising the ShExML engine through code profiling: from turtle's pace to state-of-the-art performance

This is a revised version of the paper where the author presents a report on how they investigated bottlenecks in their software, the ShExML engine, through software performance profiling techniques, and how the found bottlenecks were addressed in different versions of the software.

Compared to the previous version, this version is a major improvement. It has also been reshaped into a full paper instead of the "Reports on tools and systems" type submission and significantly extended. Now it seems more self-contained. It describes and quantifies the improvements made to the ShExML engine, which could be of interest to all users and implementers of similar software and related benchmarks. The research is original, significant and the quality of writing has improved.

Also, the evaluation seems replicable and the results are published with a long-term stable link.

My comments from the previous version were addressed and now I am happy to recommend accepting the paper.

This is a review based on a revised version of the paper, that presents how the ShExML engine is optimized to improve performance in terms of KG materialization time and resource usage. I would like to commend the author for taking into consideration the suggestions from my previous review and the other reviewers’, as I consider the paper has greatly improved from the first version.

I like much more how section 2 reads now, however I believe that “rmlmapper” is written like “RMLMapper”. Moreover, creating the a new section for describing the ShExML language has been a good decision IMO, the following sections are clearer and can be followed more easily with this context established. I’d suggest to add line numbers to the mapping listing, so that particular parts in the mapping can be referenced from the text when describing the example.

Section 4 has improved and reads better now, but it is still however not clear what are the inputs (data, mapping, both?) of the pipeline, or the different components. Sections 5 and 6 looks also better with Table 1, the violin plots and the replication of the SPARQL-Anything experiments. As a small suggestion, I’d advise to separate the groups among versions, so that they can be more easily differentiated. Additionally, it is not clear why the EHRI data is not tested in the first version.

In general, I’m quite content with the changes and modifications made for this version, I have only minor remarks to improve the paper further.

The revision addressed my concerns, and the additional benchmarks significantly improved the paper's contributions.