Description
Could the cloning of the children array in createjs.Container.draw be removed and the non-cloned children array used for iteration instead? Allocating a new array for every container for every frame puts a lot of load on the GC and can cause micro-stutters, especially on mobile devices where memory is at a premium and the GC is forced to run more often.
EaselJS/display/Container.js:156
// this ensures we don't have issues with display list changes that occur during a draw:
var list = this.children.slice();
An alternative way of addressing the issue stated in that comment would be to lock the container entirely while drawing and prevent any calls to functions that manipulate the display list (e.g. addChild or removeChild). This could be implemented by wrapping the loop in a set private "drawing" flag, and throw an error if true in display list manipulation methods.
This restriction should not cause any major issues - the only user code reachable from the container's draw method is any custom classes extending createjs.DisplayObject and overriding draw or updateContext. It is reasonable (at least, in my opinion) to impose the restriction that the display lists of the container hierarchy above the current object is locked during these methods.
If this behaviour is undesirable, an alternative alternative approach could involve caching all display list manipulation commands during a draw and processing them when the draw is complete, thus deferring any add/removeChild calls until after the draw has completed. This will remain more efficient than the current approach so long as the assumption holds that add/removeChild calls during the draw loop won't occur frequently.