You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Lingua uses ForkJoinPool.commonPool() for model loading and language detection. However, maybe it would be useful to allow users to specify their own Executor, for example with LanguageDetectorBuilder.withExecutor(Executor) (the default could still be commonPool()). This would have the following advantages:
could customize worker thread count, or even run single-threaded, e.g. executor = r -> r.run()
(Note that I have not extensively checked how well this performs compared to invokeAll, and whether exception collection from the Futures could be improved. Probably this implementation is flawed because called would wait on get() call without participating in the work.)
Alternatively CompletableFuture could be used; but then care must be taken to not use ForkJoinPool.commonPool() when its parallelism is 1, otherwise performance might be pretty bad due to JDK-8213115.
This would require some changes to the documentation which currently explicitly refers to ForkJoinPool.commonPool().
What do you think?
The text was updated successfully, but these errors were encountered:
Related to #119
Currently Lingua uses
ForkJoinPool.commonPool()
for model loading and language detection. However, maybe it would be useful to allow users to specify their ownExecutor
, for example withLanguageDetectorBuilder.withExecutor(Executor)
(the default could still becommonPool()
). This would have the following advantages:executor = r -> r.run()
It would not be possible anymore to use
invokeAll
then, but a helper function such as the following one might add the missing functionality:(Note that I have not extensively checked how well this performs compared to
invokeAll
, and whether exception collection from theFuture
s could be improved. Probably this implementation is flawed because called would wait onget()
call without participating in the work.)Alternatively
CompletableFuture
could be used; but then care must be taken to not useForkJoinPool.commonPool()
when its parallelism is 1, otherwise performance might be pretty bad due to JDK-8213115.This would require some changes to the documentation which currently explicitly refers to
ForkJoinPool.commonPool()
.What do you think?
The text was updated successfully, but these errors were encountered: