[POC] [WIP] Remove MediaSourceContentInitializer, add CoreInterface #1627
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peaBerberian
added
work-in-progress
peaBerberian
force-pushed
the
poc/common-init
branch
5 times, most recently
from
7569943 to
47b4bf7
Compare
peaBerberian
force-pushed
the
poc/common-init
branch
3 times, most recently
from
a203984 to
d97c89e
Compare
peaBerberian
added
the
skip-performance-checks
peaBerberian
force-pushed
the
poc/common-init
branch
from
d97c89e to
809f8e8
Compare
peaBerberian
added
skip-performance-checks
peaBerberian
force-pushed
the
poc/common-init
branch
3 times, most recently
from
c632c93 to
33ce62e
Compare
|
Automated performance checks have been performed on commit Tests results✅ Tests have passed. Performance tests 1st run outputNo significative change in performance for tests:
If you want to skip performance checks for latter commits, add the |
peaBerberian
removed
skip-performance-checks
This is a proof-of-concept where I try to put in common the "content
initialization" logic for our "multithread" mode and our monothreaded
mode.
The idea is to replace that mode-specific code to a very thin layer
(here called `CoreInterface`) between our "init" code (always running in
main thread) and our "core" code (in a WebWorker in "multithread" mode)
which would handle both modes:
- in multithreaded mode, it would be the part doing `postmessage` calls
and `onmessage` registering for thread communication
- in monothreaded mode, it would just do the same thing through a very
simple EventEmitter-like approach
Or written another way: "multithread" and single-threaded mode would now
share the same logic beside the communication system used at the frontier
between the main-thread and potential worker (respectively
`src/main_thread` code and `src/core` code).
The end goal is to remove a lot of code, and to reduce the difference
between the multithreaded and monothreaded logic, so our tests
(integration, manual tests etc.) actually almost test the two in one go.
There might be some performance lost due to steps we are now performing
unnecessarily when in monothreaded mode (e.g. we serialize the Manifest
structure even though it's not needed when a single thread is used, we
create another PlaybackObserver on the core even though the main thread
one could be re-used etc.). To see if that lead to a visible difference
and if it does, it shouldn't be that hard to work-around.
peaBerberian
force-pushed
the
poc/common-init
branch
from
33ce62e to
3126d2e
Compare
|
Automated performance checks have been performed on commit Tests results✅ Tests have passed. Performance tests 1st run outputNo significative change in performance for tests:
If you want to skip performance checks for latter commits, add the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #1630 as performance regression is the main risk here
This is a proof-of-concept where I try to put in common the "content initialization" logic for our "multithread" mode and our monothreaded mode.
The idea is to replace that mode-specific code to a very thin layer (here called
CoreInterface) between our "init" code (always running in main thread) and our "core" code (in a WebWorker in "multithread" mode) which would handle both modes:in multithreaded mode, it would be the part doing
postmessagecalls andonmessageregistering for thread communicationin monothreaded mode, it would just do the same thing through a very simple EventEmitter-like approach
Or written another way: "multithread" and single-threaded mode would now share the same logic beside the communication system used at the frontier between the main-thread and potential worker.
The end goal is to remove a lot of code, and to reduce the difference between the multithreaded and monothreaded logic, so our tests (integration, manual tests etc.) actually almost test the two in one go.
There might be some performance lost due to steps we are now performing unnecessarily when in monothreaded mode (e.g. we serialize the Manifest structure even though it's not needed when a single thread is used, we create another PlaybackObserver on the core even though the main thread one could be re-used etc.). To see if that lead to a visible difference and if it does, it shouldn't be that hard to work-around.