Background
Current behavior:
LanguageDetectorBuilder defines a defaultExecutor with num-processors - 1 threadsLanguageDetector uses the executor per ngram size per filtered language
While this can improve the performance in some situations (e.g. when processing long texts with a large number of / all languages), it can actually decrease performance in other situations compared to running language detection in the calling thread (e.g. short texts with a small number of languages).
Change considerations
- set an upper bound for the thread number of the default executor, or make it depent on the number of languages (or their model size / 'cost', see also below)
For example at some point the performance improvement (if any) for a higher number of threads becomes insignificant because there is simply not enough work for them.
- during language detection consider the following factors when deciding whether to run multi-threaded
- number of (filtered) languages
- length of text (respectively number of ngrams)
- size of language model
The number of ngrams per language differs, making the lookup more 'expensive' if there are more ngrams in the model (?).
- refactor the code to abstract usage of
CompletableFuture away, and allow more efficient single-threaded execution
This assumes that CompletableFuture incurs overhead, even when used with r -> r.run() as exectutor (?).
However, choosing the right conditions for this might be difficult; it might even depend on the machine running the code.
Background
Current behavior:
LanguageDetectorBuilderdefines adefaultExecutorwith num-processors - 1 threadsLanguageDetectoruses the executor per ngram size per filtered languageWhile this can improve the performance in some situations (e.g. when processing long texts with a large number of / all languages), it can actually decrease performance in other situations compared to running language detection in the calling thread (e.g. short texts with a small number of languages).
Change considerations
For example at some point the performance improvement (if any) for a higher number of threads becomes insignificant because there is simply not enough work for them.
The number of ngrams per language differs, making the lookup more 'expensive' if there are more ngrams in the model (?).
CompletableFutureaway, and allow more efficient single-threaded executionThis assumes that
CompletableFutureincurs overhead, even when used withr -> r.run()as exectutor (?).However, choosing the right conditions for this might be difficult; it might even depend on the machine running the code.