Remove internal Drivers and ThreadX support #280
Merged
Conversation
This file contains hidden or 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
Contributor
- Remove CoreExtension concept
Contributor
|
🎉 |
Contributor
Author
|
Latest results with the PR compared to latest release: |
Hopefully...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
ThreadX is a feature implemented to support offscreen canvas multithreading, however browser support for ThreadX will not come soon to our space (TV / STB market) and the current implementation has some negative side effects.
With the introduction of Drivers there is a lot of double housekeeping, maintaining two tree's of nodes, the
DriverNodeandCoreNode. This causes additional processing overhead (mainly extra function invocations and emitters) and an additional list of nodes stored in memory.In the future we should ensure all ThreadX specifics are retained in the ThreadX module, likely by providing a RendererMain replacement from the ThreadX project and proxy the CoreNode respectively as we communicate over threads. And keep the specifics to ThreadX to where they belong.
Early test results:
current master: 20k nodes create 2867ms @ 65 MB HEAP:
this pr: 20k nodes create 1272ms @ 35 MB HEAP:
About 2.2x faster and nearly 50% less memory on an excessive stress test.
Todo: