Benchmark for IRI0 vs. IRI3986 with and without IRI-Cache in SAX-parser

[arne-bdt]

When I introduced the cache for IRIs in #2744, I promised to remove the cache in case it is not needed any more with the new IRI provider IRI3986.

First: The benchmarks clearly show that IRI3986 is much faster than IRI0 and makes a huge difference. Thanks @afs!
Maybe we should use it as default from Jena 5.4 onwards?

Here is a benchmark with examples, wich are relevant to my work,, where the cache provides a better performance even with IRI3986:

Benchmark                      (param0_IriProvider)  (param1_ParserLang)  (param2_GraphUri)  Mode  Cnt  Score   Error  Units

Current implementation with IRI Cache:
TestXMLParser.parseXMLJena530                  IRI0       RRX.RDFXML_SAX   xxx_CGMES_EQ.xml  avgt   15  0,357 ± 0,007   s/op
TestXMLParser.parseXMLJena530                  IRI0       RRX.RDFXML_SAX    RealGrid_EQ.xml  avgt   15  1,084 ± 0,038   s/op
TestXMLParser.parseXMLJena530               IRI3986       RRX.RDFXML_SAX   xxx_CGMES_EQ.xml  avgt   15  0,305 ± 0,005   s/op
TestXMLParser.parseXMLJena530               IRI3986       RRX.RDFXML_SAX    RealGrid_EQ.xml  avgt   15  1,017 ± 0,020   s/op

Without IRI-Cache:
TestXMLParser.parseXML                         IRI0       RRX.RDFXML_SAX   xxx_CGMES_EQ.xml  avgt   15  0,431 ± 0,026   s/op
TestXMLParser.parseXML                         IRI0       RRX.RDFXML_SAX    RealGrid_EQ.xml  avgt   15  1,207 ± 0,014   s/op
TestXMLParser.parseXML                      IRI3986       RRX.RDFXML_SAX   xxx_CGMES_EQ.xml  avgt   15  0,333 ± 0,014   s/op
TestXMLParser.parseXML                      IRI3986       RRX.RDFXML_SAX    RealGrid_EQ.xml  avgt   15  1,102 ± 0,011   s/op

But I must confess, that there are other examples, where the cache might be slightly slower or at least does not provide any benefit when using IRI3986.

I would tend to keep the cache, as it does not seem to cause harm. On the other hand, removing the cache would reduce complexity.

What do you think?

[afs]

Excellent!

Maybe we should use it as default from Jena 5.4 onwards?

An option is Jena6, which, if Java24 is on time, woudl be endof this year (2025).

For me, switching at Jena 5.4 is also fine. The messages change, errors/warnings shouldn't.
Getting user to try things out is always a bit hit-or-miss. We could specifically say this is going to happen by an email to users@.

I would tend to keep the cache, as it does not seem to cause harm. On the other hand, removing the cache would reduce complexity.

Don't mind. The cache code looks reasonably confined to a few places in each parser.

I would tend not have "null it out" i.e. leave the code, set the overall map to null as indicating "not active". This is OK short-term but it sort of leaves the situation unclear over the long-term.