Section 8.9. Optimizing Shared Object Performance

8.9. Optimizing Shared Object Performance

While it is possible to store complex data structures such as objects or arrays in a shared object slot, doing so is often not a good idea. The reason goes back to the fact that when one property in the object or array changes, the entire data structure is copied to the remote shared object and distributed to every client. To avoid the unnecessary copying of data, shared objects should be designed to reduce redundant updates. For example, a natural and seemingly logical way to design a list of users would be to create a shared object with each property value containing an object with information about each user . In SSAS we might create a structure like this:

 userList_so = SharedObject.get("public/userList"); userList_so.lock(  ); userList_so.setProperty("blesser", {cn: "Brian Lesser", status: "Offline"}); userList_so.setProperty("peldi", {cn: "Giacomo Guilizzoni", status: "Offline"}); userList_so.setProperty("reinhardt", {cn: "Robert Reinhardt", status: "Offline"}); userList_so.unlock( ); 

Although this approach seems logical (in that it keeps information about each user in one object), it will waste network bandwidth. In this case, imagine that the status property of the object in each slot is regularly updated to show when a user is online, away from her computer, busy, offline, and so on. Each time the status property changes, the cn (common name ) property and its data will be sent to every client as well. One common solution to this problem is to use separate shared objectsone for personal information and another for status information. When separate objects are used, each movie must know what shared objects it should connect to. The most common way to work this out is to have separate objects or components look for their own shared objects based on some prearranged naming convention. A user list movie clip or component will attempt to connect to a shared object named userList , and a status movie clip or component will attempt to connect to a shared object named status . An alternative scheme is to use separate slots in the same shared object as described earlier in the second item in the list under "Avoiding Collisions."