Speedup initialization of charset AutoDetectReader required for language detection

[sebastian-nagel]

Most time required for charset detection is spent to initialize the AutoDetectReader and to load the list of EncodingDetectors from jar/job file. It should be possible to speed this up.

[tfmorris]

Since the list of detectors is static, you should be able to cache it. You could try using this constructor to pass in a ServiceLoader. There's also a private constructor which takes a list of detectors directly, avoiding all lookup overhead (although I suspect that the class loader caching will do what you need if you just reuse the ServiceLoader.

p.s. Since cloned repos aren't searchable on Github (annoying!) here's the relevant source file: LanguageDetector.java

[sebastian-nagel]

Thanks, @tfmorris. Yes, I could overwrite the ServiceLoader and cache the list of classes implementing EncodingDetector. Looks like I have to instantiate them every call because detectors may be stateful. Actually, it's a known issue in Tika (TIKA-1568), I'll first try to get it solved there.

[sebastian-nagel]

For a detailed analysis, please check the interactive SVG.zip.

[tfmorris]

Getting the Tika folks to fix it would definitely be my first choice! Even if you had to re-instantiate them, I think you'd be way ahead because the bulk of the time is going to ServiceLoader.identifyStaticServiceProviders() and that list is never going to change so all those repeated JAR file lookups are just a waste. Class loading and instantiation is a minuscule fraction of the time.

[tballison]

Which version of Tika are you using? How are you constructing your parser(s) and or reusing it/them

We've been caching encoding detectors if you do a single call to, e.g., new AutoDetectParser() and then use that throughout. When each parser that extends AbstractEncodingDetectorParser is created, the encoding detector is created for that parser and then reused.

Sorry...let me look at AutoDetectReader directly... So, y, we've done that in our parsers... let me take a look for AutoDetectReader...

[tballison]

Done (almost)!

https://issues.apache.org/jira/browse/TIKA-1568?focusedCommentId=16883215&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16883215

[tballison]

Sorry for the idiocy, but can you tell me what profiler you used to get the image above?

[tfmorris]

The profile is referenced in one Sebastian's other performance issues. It is async-profiler.

[tballison]

@tfmorris Thank you!

[sebastian-nagel]

Hi @tballison, in case it is still relevant: Tika 1.20 was used and here the call of AutoDetectReader. I'll try your fix tomorrow. Thanks!
Async-profiler is great: small footprint (one jar file, one shared object and a shell script), only the PID is required, no Java options at startup of the profiled process, profiles both Java and native code. The limitations: Unix only (Linux, MacOS) and (usually) root privileges are required to enable the perf events.

[sebastian-nagel]

Solution confirmed, see TIKA-1568. I'll use the Tika 1.22-SNAPSHOT jars for now (not committed because this requires to carefully test everything after each build), the issue will be finally fixed when the Tika dependencies are upgraded to 1.22.

[sebastian-nagel]

Profiler screenshot after the fix of TIKA-1568: