Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support specifying custom Executor #145

Open
Marcono1234 opened this issue Aug 1, 2022 · 1 comment
Open

Support specifying custom Executor #145

Marcono1234 opened this issue Aug 1, 2022 · 1 comment

Comments

@Marcono1234
Copy link
Contributor

Marcono1234 commented Aug 1, 2022

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 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()
  • could customize worker threads:
    • custom name to make performance monitoring easier
    • custom priority

It would not be possible anymore to use invokeAll then, but a helper function such as the following one might add the missing functionality:

private fun <E> executeTasks(tasks: List<Callable<E>>): List<E> {
    val futures = tasks.map { FutureTask(it) }
    futures.forEach(executor::execute)
    return futures.map(Future<E>::get)
}

(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?

@pemistahl pemistahl added this to the Lingua 1.3.0 milestone Oct 24, 2022
@pemistahl
Copy link
Owner

This sounds like a good idea. I will implement this for the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants