Matt: Thanks, Jack _____
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin Sent: Monday, February 05, 2007 11:54 PM To: [email protected] Subject: RE: [flexcoders] Large Application SWF Size Sorry, I don't think we have any docs like that. Sounds like a good community project :-) I think that nested Boxes will add more to the runtime memory than directly to the SWF size because there are more objects instantiated at runtime to manage the layout. So doing constraints for a large number of screens might be slightly more efficient because less objects will be created, but I don't know that it will have a huge impact on the size of the SWF itself. Sure, it may reduce the SWF size somewhat simply because less objects need to be created so there's less code-gen, but that's not related to the object type. Matt _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Caldwell Sent: Monday, February 05, 2007 8:27 PM To: [email protected] Subject: RE: [flexcoders] Large Application SWF Size Matt: Is there any documentation that tells us what each component adds to a SWF's size? Like a Panel, HBox, VBox, etc. My understanding is that nested HBox(s) & VBox(s) add more to a SWF's size than other methods. Am I correct in thinking that 200 MXML files with 10 nested HBox(s) and/or VBox(s) would create a much larger SWF than the 200 MXML files where layout=absolute and I used x/y and/or top/bottom for layout control? What do you recommend? Thanks, Jack _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin Sent: Monday, February 05, 2007 7:32 PM To: [email protected] Subject: RE: [flexcoders] Large Application SWF Size Ah, sorry for misunderstanding, I think I could have re-read that :-) I guess I'd recommend the same experiment, it should tell you the overhead in size of having a class vs including the code inline. Extra classes absolutely add size; the question is how much size. It should be on the order of 10s of bytes I would think, though multiplied by 200 that may be significant for you. Matt _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Caldwell Sent: Monday, February 05, 2007 5:11 PM To: [email protected] Subject: RE: [flexcoders] Large Application SWF Size Matt: I guess I did not explain it very well. I did not mean 200 screens in the same MXML, but rather 200 screens = 200 MXML files. Take for example that each screen had its own subMenus. Would it be better to put the subMenu and main screen code in one MXML or have two files as regards to SWF size? It is the same amount of code just in 2+ files. That's what I meant by 200 MXML files versus 400 or 500 files. Hope this explains it better. Thanks, Jack _____ size=2 width="100%" align=center tabIndex=-1> From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin Sent: Monday, February 05, 2007 6:33 PM To: [email protected] Subject: RE: [flexcoders] Large Application SWF Size I gotta tell you that I think the MXML compiler would slow down significantly for 200 screens in a single MXML file. That just seems insanely huge. I haven't done any experiments but I can't imagine that the savings you'd get in size (if any) would outweigh the pure nightmare of trying to work with something so big. As an experiment, write a few MXML components with just the root tags (say Panel, VBox, Canvas), then write an application that uses all those components. Then basically replace the MXML that used the components with just those tags. You'll be able to see the additional weight that having class signatures add. You can do a similar experiment with AS where you write some classes with a single function, instantiate them and use them. Then remove the instantiations and move the functions to the main class. It's not perfect but will give you a rough sense. Matt _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of jwc_wensan Sent: Monday, February 05, 2007 4:17 PM To: [email protected] Subject: [flexcoders] Large Application SWF Size To All: I know we can now implement modules now, but even the modules may become large. For this discussion, let's look at just a single large application . . . . Would we be better off with 200 views/screens with all the code in the MXML files or the same code split among 400 or 500 MXML files? The same question applies to AS files: Combine or split? While I realize that it might be easier to maintain code with multiple MXML/AS files, what impact does that have on the SWF size when you are talking about this many files? Thanks, Jack
