Notes on AS3 Editor

While building an AS3 Editor i faced some performance issues which was only able to be solved by applying many optimizing techniques like : buffering, caching, string indexing, binary search, lazy loading, dirty flags … This note will give a brief an insights onto the problems and the techniques used.

Linked List

It’s a rumor that Linked List should be a better Data structure to choose if we only need to traverse linearly one after another, without the need of randomly access, plus the ability to remove/ insert items at arbitrary positions.

For 1000 items double linked list

1. Pushing items into the first, or last position is 15x faster than put items randomly as we need to search for the correct position, as an important side note : searching time will go up linearly with the List size.
2. Pushing items into Array is much faster than insert into first/last position of the list : Push/Pop is 4x faster and even randomly splice is 1.2x faster.
3. List seems to use much more memory than Array, about 5x more, as each node of the list is an Object, that has at least 2 variables refer to prev and next items.
4. Traverse from first to last item is 2x slower than the same task with Array.
5. Checking existances using indexOf in both Array and List is not efficient, it’s very slow as we need to traverse one after another to find out.
6. For huge number of items, list operations should go linearly while Array won’t

onAS3EventSystem();

While building a basic Event system is not a big problem in AS3, take into accounts all special cases can be very troublesome. Some of the most significant ones are

Priority – how can we handle events more effective ? the numbering sorting priority system seems to be ugly, non dense and can not ensure things to work correctly. What if a component thinks that it should be call first, or call last, then another one thinks that, too ?

Cancelable – it will be based on the priority, how we can ensure that our callbacks would stop the dispatching stream before any other guys get updated. Should we have some kind of internal dispatching / callback to update internal things first ?

Recursive – there are case when we click something, active it, then on the handler, after doing something, we set active back to some other value, the event system may not be working as expected ? May be we should add some variable and check if it’s dispatching, if yes, just defer new dispatchings till next frame

Loop back – while we are trying to use some set of components that are someway bind to another, changing one can dispatch an event to change another, which can be looped back to change the dispatch source, which can cause an unstoppable loop for normal case, and blink loop for defer dispatching case (defer dispatching won’t solve this). We can add some kind of changes detection before dispatching, but it can be not accuracy after some data conversion, particularly for Numbers where we need to take round off errors into account.

Validation – before sending update to all the registered listeners, we may need to validate the value to ensure the changed value is valid. How can we do that? What if there are not only one validators out there, and then will their priority affects ?

Update skipping – While it’s best practice trying to update the View based on Model event, there are some case that updating the view directly boost the performance dramatically. How we handle this case ? can we add some kind of dispatching target (not the Dispatching Object itself) so we can check and skip / only update necessary things while getting the event back from Model ?

Hooking

Hooking provides a lightweight way to add flexibility to applications, especially for components. We just can not handle all types of skins, themes and interactions internally as it is too complex and vast, instead, allow some kind of hooking will allow user to handle things their way without the need of reading and understanding how things work internally.

Let’s see a simple sample for size-handling ! Let’s say we have a component base class

package {
	public class AComponent {
		// ...
		public function setSize(w: int, h: int): void {
			//do skin handling here
		}
		// ...
	}
}

As we can see we will need to do all supported skin resizing inside setSize function to enable skin to change its size. Let’s think of the various cases when the skin is just a simple textfield, a bitmap, or a sprite contains a textfield, or a sprite contains many other sprites (bg, border, textfield …) how our almighty setSize handle that ? just can’t with all possible cases, right ? And we usually agree on a compromise solution that we will only support some type of skins or defining some naming rules that user must follow in order for the component to woks. This will work for most cases although we will need quite a bit of work but it’s worth to note that there are special cases that user just can not fit their need into our rules … what will they do then ?