You can profile a Flex 2 app in the Flex 3 profiler. You can profile any debug swf really.
IE never worries, it just keels over and dies. Here's my top-five: 1. SWF size is not going to be your issue as much as run-time memory. I've heard of folks with multi-MB swfs and they aren't complaining that IE can't handle it. All complaints I've seen is about how much process memory (on Windows, the memory number you'll see next to your iexplorer.exe instance in the Task Manager) the application uses up and that, when it gets too big, IE dies. The number I keep hearing is in the hundreds of MBs. OK, so folks on slow networks wish the SWF was smaller so it would download faster, but once you get past that, it is all about run-time memory. 2. The Flex 3 Profiler can definitely help you tune your application, but it does not report the same numbers as the Task Manager because it only reports actionscript objects and not all of the other resources the player uses from the OS such as, on Windows, DIBs, HWNDs, DCs, etc. If you suck in lots of huge images, the Profiler will not show that but the Task Manager will, and that's the fastest way to get IE to choke. 3. Modularity is always a good thing. Pay as you go is usually a good thing. Only loading what you need and getting rid of it when you don't need it is usually a good thing. 4. "Modules" is a feature designed to assist the development of large applications by not requiring that you compile and link every byte of the SWF on every change, and to assist startup time by allowing you to load the SWF bytes you don't need at startup after startup. A single SWF will use less run-time memory than the same SWF broken into modules unless some of those modules are never loaded or get punted when no longer needed. 5. Application run-time memory usage can be code-bound, display-object bound or data-bound. A medium-sized app (500K SWF) I just looked at used up 35MB of process memory at startup. Roughly 10MB is just IE, another 10MB is the Player and of the remaining 15MB, 80% was attributed to the code. SWFs are zipped and expand at about 3:1, then are JIT-ed to machine code and other structures are setup to support classes, methods, etc. A SWF does not run from its binary as much as an .EXE file does. That app is considered code-bound, at least at startup. Now, every UIComponent is at least 6K, controls and containers are proportionally larger, so somewhere short of 1000 display objects, you've sucked up 6MB or more. 1000 seems like a lot, but it is 10 tabs in a tabNav with a 10x10 datagrid on it. Charts may have lots of display objects too. So if you have lots of grids and charts and not a lot of code, then you are display-object bound. Start bringing in bitmaps or requiring bitmap caches, and you'll definitely be display-object bound. Finally, some apps bring in 10000 data records, some which are deeply nested. A simple bindable object is at least 50 bytes so with complex data objects, you can really eat up tons of memory and be data-bound. How you optimize for each scenario is pretty straightforward, but you have to know which scenario you are in, and the Profiler is not going to fully measure the memory that goes to code and display objects. Hope that helps, Rick's responses were definitely more fun to read. -Alex ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Josh McDonald Sent: Thursday, May 08, 2008 9:12 PM To: [email protected] Subject: Re: [flexcoders] How big does a SWF get before IE starts to worry? Thanks for those tips, although I don't think I can action any of them on this project, given it's targeting Flex 2 (no profiler, no rpc source), I'm in Brisbane (unlikely there's any training that will benefit my skill level unfortunately), and I'm already a full-stack JEE ninja ;-) I'm definitely hoping we don't have to switch this project to modules, as it's 3/4 done already, I've been thrown in because there's some serious deadlines approaching, and I was just mainly wondering about how much leeway we'll have as the SWF for this is already over a meg. It's not CRM, but it's not a dashboard widget either ;-) -J On Fri, May 9, 2008 at 1:53 PM, Rick Winscot <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: If you are creating widgets or gizmos with Flex/Flash... I don't think you will ever hit the 'pain threshold.' However, if you are developing a substantive application - workforce management, crm, data management, repository, asset management or the like... realistically you can code up to release oblivious of what is happening with memory management and system performance. The difficulty is that developing in Flex is so freaking cool that you can easily get caught up in features and visual sweetness that you'll will forget to profile as you go to help you target bottlenecks. Frankly - if you save performance tuning til' the 11th hour... it's going to be rough. It's not just about the size of the swf - it all about coding to the platform... most reasonably configured system will be fine. Here is a top five-ish list of things to think about. #. Modularize your app - you _can_eat a whale... one bite at a time. #. Profile as you go - if you start to see 'the signs' stop and figure out what the problem is. If you are patient the knowledge you gain in the process will provide a feedback loop re-injecting better approaches and broader understanding into your work. #. Training... there I said it. Spending a few bucks in a session with a guru will be incalculable. #. Source. Source. Source. It's all about looking into the Flex SDK source as much as you can. Building 'hot rods' is a process of developing (fanatical) deep understanding of your subject - to the point you know when to bend the rules and when not to. #. Become the solution. Let's face it... in order to be a Flex 'rockstar' you are going to need to understand enterprise architecture, drool in sql, pound (as in eat large quantities of) webservices/servlets/etc, and... well you get the point. Buy some books... lots of em. Take a (qualified) nerd/geek out to lunch. Ask to see cool things people 'talk' about and then ask to take a look at the source. Cheers, Rick Winscot From: [email protected] <mailto:[email protected]> [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Josh McDonald Sent: Thursday, May 08, 2008 10:51 PM To: [email protected] <mailto:[email protected]> Subject: [flexcoders] How big does a SWF get before IE starts to worry? Hey guys, I've been reading a lot about explorer not being so nice with Flex / Flasg apps that use up a bit of memory, and I'm wondering at what kind of thresholds this starts to become a problem? Is it mainly about SWF size, or how loose you are with your allocations and leaving dead references around? -J -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
