Developer Journal: Memory Optimization
The next release candidate for 1.11.0 will be out very shortly, but I thought it best to post a brief update on the past week’s work as this week saw a concentrated effort on core optimization.
First we took another look at the use of
arguments lists throughout the framework and found several more occurrences of it being accessed in an inefficient manner. Depending on the browser, accessing
arguments in such a way that causes it to be allocated can be up to 80% slower and so it’s really good to have these all fixed.
As I mentioned, this has been very difficult, but we’ve been steadily identifying and replacing Objects (hashes) and Arrays with single shared versions wherever possible. This includes some key high touch areas in SC.View’s layout code and SC.Event’s architecture. In fact, a major refactor of SC.Event was completed in order to re-use a single shared normalized event instance per event type. This means that whereas previously each event (e.g.
touchmove) would allocate a new normalized SC.Event each time, it now re-uses just the one. The affect of all of this work is a slightly flatter memory profile with fewer and smaller saw-tooth garbage collection drops in it. It’s not perfect yet and it’s likely impossible to not allocate a bit of memory on each event, but some exciting progress is being made.