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

Optimization: resizable workers array #3137

Merged
merged 6 commits into from Jan 17, 2022
Merged

Optimization: resizable workers array #3137

merged 6 commits into from Jan 17, 2022

Conversation

elizarov
Copy link
Member

@elizarov elizarov commented Jan 12, 2022

Instead of allocating an array of maxPoolSize (~2M) elements for the worst-case supported scenario that may never be reached in practice and takes considerable memory, allocate just an array of corePoolSize elements and grow it dynamically if needed to accommodate more workers.

The data-structure to make it happen must support lock-free reads for performance reasons, but it is simple, since workers array is modified exclusively under synchronization.

Instead of allocating an array of maxPoolSize (~2M) elements for the worst-case supported scenario that may never be reached in practice and takes considerable memory, allocate just an array of corePoolSize elements and grow it dynamically if needed to accommodate more workers.

The data-structure to make it happen must support lock-free reads for performance reasons, but it is simple, since workers array is modified exclusively under synchronization.
@elizarov elizarov requested a review from qwwdfsad Jan 12, 2022
elizarov and others added 2 commits Jan 14, 2022
Co-authored-by: dkhalanskyjb <52952525+dkhalanskyjb@users.noreply.github.com>
@elizarov elizarov requested a review from dkhalanskyjb Jan 14, 2022
@elizarov elizarov requested a review from qwwdfsad Jan 14, 2022
@qwwdfsad qwwdfsad merged commit a1f5ab8 into develop Jan 17, 2022
1 check passed
@qwwdfsad qwwdfsad deleted the resizable-workers-array branch Jan 17, 2022
yorickhenning pushed a commit to yorickhenning/kotlinx.coroutines that referenced this issue Jan 28, 2022
Instead of allocating an array of maxPoolSize (~2M) elements for the worst-case supported scenario that may never be reached in practice and takes considerable memory, allocate just an array of corePoolSize elements and grow it dynamically if needed to accommodate more workers.

The data structure to make it happen must support lock-free reads for performance reasons, but it is simple since the workers array is modified exclusively under synchronization.
elizarov referenced this issue Feb 4, 2022
….IO unbounded for limited parallelism (#2918)

* Introduce CoroutineDispatcher.limitedParallelism for granular concurrency control

* Elastic Dispatchers.IO:

    * Extract Ktor-obsolete API to a separate file for backwards compatibility
    * Make Dispatchers.IO being a slice of unlimited blocking scheduler
    * Make Dispatchers.IO.limitParallelism take slices from the same internal scheduler

Fixes #2943
Fixes #2919
@slavonnet slavonnet mentioned this pull request Feb 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants