Signal - memory optimization / reductions #1359
Merged
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.
There are a fair amount of Signal objects created. In the current
implementation these are somewhat "fat" objects for two reasons:
dispatch
is created for each new Signal - thisincreases the retained size by 138+ bytes/Signal in Chrome.
default value, and the bindings array is always created, even if never
used.
This change "lightens" the Signals such that there is significantly less
penalty for having many (unusued) signals.
As an example of how much this does play a role, in the "Random Sprite"
demo ~2000 Signals are created, with only 12 of these signals being
subscribed to. This results in a shallow size of ~300K and a retained size
of ~600K (which is almost as much memory as required by the
Sprites/Sprites themselves!) for .. nothing.
With these changes the shallow and retained sizes are less than 50K each -
and this is with only ~200 sprites!
This change addresses these issues by
Changing it so there is no
dispatch
closure created. This is abreaking change (although there is no usage of such in core where it
breaks); the code referenced "No destroy method on State class #24", but no such [relevant?] issue could be found on
github.
In the rare case that code needs to obtain a dispatch-closure, the
boundDispatch
property can be used to trivially obtain a (cached)closure.
The properties and default values are moved into the prototype; and the
_bindings
array creation is deferred. This change, coupled with theremoval of the automatic closure, results in a very lightweight
~24bytes/object (in Chrome) for unbound signals.
This is minor breaking change, as per the removal of the automatic
closure; but no such need/usage was found in the core. (There may be cases
in the examples, which were not checked.)
If merely opting for the array creation delay and keeping the default
properties in the prototype the shallow size is still halved; less
significant but still a consideration.