Thanks for that Alex, I'd always thought there was some compile-time voodoo Fx3 did that enabled the debugger. That's good to know.
-J On Fri, May 9, 2008 at 3:51 PM, Alex Harui <[EMAIL PROTECTED]> wrote: > 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:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On > Behalf Of *Josh McDonald > *Sent:* Thursday, May 08, 2008 9:12 PM > *To:* flexcoders@yahoogroups.com > *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]> > 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:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On > Behalf Of *Josh McDonald > *Sent:* Thursday, May 08, 2008 10:51 PM > *To:* flexcoders@yahoogroups.com > *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] > > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [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]
