Compared to direct method calls: bad. Here a short benchmark and the code I wrote for this benchmark (needs PHP 5.3):

define('ITERATIONS', 2000000);
    function doBenchmark($name, Closure $closure){
        $start = microtime(true);
        for ($i=0; $i < ITERATIONS; ++$i) {
            $closure();
        }
        $stop = microtime(true);
        echo "Test $name: " . ($stop - $start) . " seconds";
    }

    class Test{
        public $data = array("view" => "view", "test2" => "test2", "test3" =>"test3");

        public function getView(){
            return $this->data['view'];
        }

        public function __call($name, $arg){
           return $name=="_getView" ? $this->data['view'] : false;
        }

        public function __get($key){
            return array_key_exists($key, $this->data) ? $this->data[$key] : null;
        }
    }

    $t = new Test();
    doBenchmark("Methode Call", function(){
        global $t;
        $v = $t->getView();
    });

    doBenchmark("Direct Access", function(){
        global $t;
        $v = $t->data['view'];
    });

    doBenchmark("Magic Methode (__call)", function(){
        global $t;
        $v = $t->_getView();
    });

    doBenchmark("Magic Methode (__get)", function(){
        global $t;
        $v = $t->view;
    });

So, you get the picure

Don’t use magic methods as a replacement for a regular method if a direct access to a field or variable is possible. Magic methods are the sugar for dynamic created attributes (eg. for database objects) or if you don’t know the method/attribute while writing the code.

Use magic methods only rarely.

The only special magic method you should use often: __autoload It helps to load your needed classes on demand only when they are needed. If you use namespaces, here a short trick to load the name-mangled classes (the $path must of course be changed to your needs):

function __autoload($class) {
    $parts = explode('\\', $class);
    $class = end($parts);
    $path = __DIR__ . "/includes/"); //path for the includes

     require ($path . $class . ".php");
}

Happy coding

The difference

Don’t forget: Flash != Flex. Flex uses elements from Flash but is built on own classes. If Flash and Flex should play together we need a interface.
MovieClip is a display object in Flash and UIComponent is a display object in Flex. But we can wrap a MovieClip into a UIComponent, so the Flex UIComponent becomes a container for our Flash MovieClip.
Here both files, at first the MXML file:

And the Actionscript file with the class:

package {
	import mx.core.Application;
	import mx.core.UIComponent;
	import flash.display.MovieClip;

	/*****************************************************************
	 * File: FlexApp.as
	 *****************************************************************/

	public class FlexApp {
		private var _app:Application;

		public function FlexApp(app:Application) {
			_app=app;

			var btn:MovieClip=new BtnStop();
			var flexui:UIComponent=new UIComponent;
			flexui.addChild(btn);
			app.addChild(flexui);
		}

		static public function initApp():FlexApp {
			return new FlexApp(Application(Application.application));
		}

		public function get app():Application {
			return _app;
		}
	}
}

How it works

applicationComplete in the MXML file is the eventhandler called from the application. Here we provide our handler, which must be a static member function of a class so it can be called later.

initApp() creates our class and passes a application object to the constructor.

Inside the constructor we create the MovieClip from the imported Flash symbol “BtnStop” (this symbol comes from a swc lib, created with Flash). Then we create a Flex UIComponent container and add our MovieClip as a child. The UIComponent can now be added as child of the Flex application.