Some notes:

AVM2 architecture - SWFs have byte code which is just in time (JIT) compiled to native code

JIT's job:
- verify and optimize byte code
- generate native code

Tools for optimization:
- flash.utils.getTimer
- trace
- Flash Debug Player
- Flex 3 Builder Performance Profiler
 
3rd Party Tools:
- REDbug
- Firebug
- Flash Tracker

Graphics:
- minimize usage of full screen scrolling and effects
- minimize unnecessary animations
- if using animation and want to hide something, instead of making it invisible, remove it from the display list and then add it later

General:
- Optimize memory foot prints
- Use deferred instantiation
- Remove listeners or object reference
- Remove debug code trace statements
- Set compiler option optimize=true (default)
- instatiating objects inside loops when you could have instantiated it once and updated props
- non-typing is a bad thing with respect to optimization

Found while comparing Optimized vs Non-Optimized code:

- weak references have a negative performance hit, e.g.:
      
      var o:Object = (data: "My Data", label: "My Label");
      o["data"] = "My New Data";
  
- continually looking up the same property, e.g.

      if (o.prop == "Something" ||
          o.prop == "Something Else" || 
          o.prop == "Even Something Else) {

            vs.

      var prop:String = o.prop;
      if (prop == "Something" || 
          prop == "Something Else" || 
          prop == "Even Something Else) {

- getting an object out of an array and not casting it first before calling a method (i thought this one was interesting), e.g.:

      myArray[3].doSomethingCool();

            vs.

      var myObject:MyObject = myArray[3] as MyObject;
      myObjet.doSomethingCool();

- keep arrays densely packed

- use constants for instatiated vars that are the same and used more than once, e.g.

      this.scrollRect = new Rectangle(0, 0, 100, 100); 

  statement done more than once, make a const instead and assign it

- for loop counters, uint/int is faster than Number

- for loop over an array upper bound comparisons, assign .length to a var and compare against that

- try/catch  takes longer in simple cases than checking conditions before accessing a prop, e.g.:

      try {
         ...
         len = myObject.child.child.length;
         ...
      } catch (e) {
         ...
      }

            vs.

      len = -1;
      if (myObject != null && 
          myObject.child != null && 
          myObject.child.child != null) {
         len = myObject.child.child.length;
      }

  in this example, the try/catch was 100 times slower!!!