OSX Flex app is slow...
So I tried my scheduling software on my mac today. It took about 18 seconds to calculate my schedule on my duo-core 2ghz MacBook Pro.
My home WinXP 2.1ghz DuoCore2 based machine takes 2 seconds. A 9x improvement.
But the shocker... my work WinXP laptop with a 1.7ghz Pentium M, a MUCH slower machine, takes about 4 seconds.
Why is the Mac so much slower on compute intensive actionscript?
I've heard of it being slower on graphical animation type things, but not something like this.
My home WinXP 2.1ghz DuoCore2 based machine takes 2 seconds. A 9x improvement.
But the shocker... my work WinXP laptop with a 1.7ghz Pentium M, a MUCH slower machine, takes about 4 seconds.
Why is the Mac so much slower on compute intensive actionscript?
I've heard of it being slower on graphical animation type things, but not something like this.
Labels: AgileAgenda, Flash, flex, Schedule
posted by Marc at
11:05 AM
9 Comments:
Actually it is also dependent on what browser you are running the Flash Player under. Each browser allocates memory and system resources differently.
1. Do you defer any AS3 execution/work across frames or are you doing all the work in 1 loop?
2. What does it do that is so burdensome?
3. Can you post some code?
I have seen apps vary in performance more due to the browser in use than platform per say. Using IE is much faster than FireFox in terms of memory allocation and OSX/Safari is even more stingy.
Post some code, I am sure there is a gap here.
Cheers,
Ted :)
By
Ted Patrick, At
7/25/2007 1:01 PM
I tried it in safari, firefox and an AIR application.
The code is roughly...
timer = new Timer(1,0);
timer.addEventListener( TIMER, myFunction);
private function myFunction()
{
This does a chunk of work consisting of a loop through a few arrays, and doing a bunch of numeric and date calculations.
}
I've tried several timer intervals thinking that might affect it, no go.
By
Marc, At
7/25/2007 2:55 PM
What Ted said. The clearest path I've seen to determining actual performance on a given machine is to do a fresh start and just open a Projector, no browser.
I'm not sure of the easiest way to create a standalone from Flex, and haven't yet seen performance benchmarking for beta AIR (did you see a difference?). Getting the Mac browsers out of the equation is a needed first step.
jd/adobe
By
Anonymous, At
7/25/2007 3:38 PM
I've had much the same problem with a nested set of Flex containers. Just moving between one screen and another is soooo sssslllllooooowwww. I wonder if Adobe is aware on of how slow flash is on the mac?
By
Anonymous, At
7/25/2007 7:49 PM
Ok, I found it. This line of code says it all:
timer = new Timer(1,0);
This will execute your function every millisecond, some 1000 times per second and 60000 times per minute. This is asking the player to do a ton of work, actually 60000 tons per minute.
If you want a chunk to run every second do this:
timer = new Timer(1000,0);
So how do I know this, I have done the same thing myself. It is a pretty common mistake with the new Timer class.
The player will attempt to do all the work you ask it to, the key is asking it to do just enough to get your work done.
Don't abuse Flash Player with the Timer class. :)
Regards,
Ted Patrick
By
Ted Patrick, At
7/25/2007 10:08 PM
The timer is in there so I can do chunks of work at a time. Is there a better way to do a chunk of work, let the flash player handle any events, then do another chunk?
I've tried various timings, all the way up to a second, the processing of the work is always at least 9x slower on OSX than Win.
By
Marc, At
7/26/2007 5:34 AM
Marc,
This code will execute indefinitely as you pass a 0 as the "repeatCount". A better strategy would be to create Timer objects and have them dynamically created.
The slowdown in OSX is because you are executing something 1000 per second with this:
timer = new Timer(1,0);
timer.addEventListener( TIMER, myFunction);
vs 1 time per second like this:
timer = new Timer(1000,0);
timer.addEventListener( TIMER, myFunction);
The key is that you have a bunch of work you need complete. You need to define storage to hold the results of all this calcuation and the state where you left off.
1. Create a timer like so:
timer = new Timer(1,1);
timer.addEventListener( TIMER, myFunction);
this will only run 1 time. Within the myFunction create a new Timer intance as 'timer' if you need to do more work. You can reuse the base function. When the work is done a new Timer will not be created.
They way I am seeing the code you posted, this will run forever and at 1000 per seconds, the player is completely overloaded. The key is to do incremental work within each Timer over time.
Making timer calls 1000 times per second is abusive to the player and is most likely degrading performance more than the work you are doing.
Again if you could post the code you are running in the myFunction it would help too. I can image there are optimization there too.
Feel free to take this offline with me at ted@adobe.com.
Happy to help!
Ted :)
By
Ted Patrick, At
7/26/2007 8:09 AM
I removed all mention of timers and did the calculation in a single pass.
OSX is still about 10x slower than the PC version.
I will run it through the FB3 profiler at some point and try to figure out why.
By
Marc, At
7/26/2007 10:06 AM
This comment has been removed by a blog administrator.
By
Anonymous, At
2/06/2008 4:22 AM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home