Bloat is almost entirely due to code size. 10M out of 13.1M was code. Further, fully 25% of our entire startup bloat--including data--is the content+layout dll. Things we can do here:
Bloat is also due to fragmentation, as evidenced by an open-2-windows, close-2-windows, open-2-windows cycle where the last two steps do not change the heap size. I suppose some objects in maxheap just stick around when we create new windows, for example, and when the memory is reclaimed it cannot be given back to the OS because of that. One potentially effective way to find out what is going on would be to bring up a new window, close that window, and look at memory to see what objects are still around. We could also have per-docshell allocators for elements and frames that reclaim memory when the docshell goes away, but I don't think we can avoid memory fragmentation with that--the OS gives us a contiguous block of memory.
Non-embedding bloat is very high (7M out of 19.8), indicating problems with chrome and history, as shown by the (mozilla - mfcembed) number. Chrome overlays are one problem (we load more stuff then we need). I believe that XBL is a big problem myself (see the Eternal XBL Form Control Problem). XBL handlers are thought to be one of the culprits, one of the major problems being that key events create one event listener for each key; I also suspect not enough sharing of the bindings in general. History (the list of URLs, titles and dates you visited stuff, which is fully loaded on every startup) takes up a very large percentage of memory, too, according to jrgm--1M for 9 days of active data. Probably because of an excessively verbose storage system.
Timeline:
Mozilla after loading 2 pages: 19.8M
Same Mozilla after pageload test: 26.75M
After another pageload test: 26.85M
After opening a second window and loading 2 pages: 26.4M (-400K!)
After pageload test on second window: 28.9M
Open 2 more windows: 29.3M
Close both new windows: 29.3M
Open 2 more windows again: 29.3M
mfcembed after loading 2 pages: 13.1M
Mozilla's memory hogging is going to be what drives me to use IE. I've tried switching to Thunderbird, but it's just as bad. Right now I've got a Mozilla running (42.8MB) and a Thunderbird (46.9MB) and my system is slow as a dog. I dare not minimize Thunderbird or suffer 5-10s of swapping delay. :-( :-( :-(
Posted by: Tom Hundt at July 28, 2003 4:48 PMIf an application is designed well, the reward for users is that they will learn it faster, accomplish their daily tasks more easily, and have fewer questions for the help desk. As a developer of a well-designed application, your returns on that investment are more upgrade revenue, reduced tech support, better reviews, less documentation, and higher customer satisfaction. The rewards of building a good-looking Aqua application are worth taking the extra time.
Posted by: Dolora at January 24, 2004 8:49 PMSo far in these articles, I have only dipped a toe or two into Aqua's pool. I have covered basic aspects of building an Aqua-compliant application, including the building of photo-illustrative/3D application icons. Now it's time to address other components of our Mac OS X application.
Posted by: Drugo at January 24, 2004 8:49 PMBy building an application that takes advantage of Aqua's many facets, you help ensure that your application will not only look good, but have a chance of becoming a raging success. After a new user clicks on the icon of your program, the first thing he or she sees is the application interface. I know that when I review a product, I am very critical of its visual design. I usually have a short time to learn the new software, so design and ease of use are very important. Aside from those who marvel at the beauty of the command line, most users tend to react the same way.
Posted by: Gregory at January 24, 2004 8:49 PMTo help you become a good Aqua citizen, Apple has created a few guidelines. I've put together a brief overview of them, and we'll be tackling many of them in the months to come.
Posted by: Basil at January 24, 2004 8:50 PMDrawers. Similar to Sheets, this is a "child" window that gives users access to items that do not always need to be present. But when do you use a drawer and when do you use a palette?
Posted by: Ingram at January 24, 2004 8:51 PMThe simple fact is that, when all other factors are equal, where will consumers spend their money? I believe that in the long run, the best looking, easiest-to-use applications will also be the most successful. I think that's why Apple encourages developers to write programs that are 100 percent Aqua-compliant.
Posted by: Hamond at January 24, 2004 8:51 PMAdhere to File Locations. Make sure that when your users save documents, your application knows where to put them and also gives users flexibility.
Posted by: Jesse at January 24, 2004 8:51 PMAdhere to System Appearance. Does your application use all the sweetly colored buttons, delightfully shaded windows, and all the other "bells and whistles?"
Posted by: Rosanna at January 24, 2004 8:52 PMThis topic is one we will tackle later in this article, but it refers to making sure that your application and the dock aren't fighting it out for supremacy of the screen.
Posted by: Jennette at January 24, 2004 8:52 PMFor example, if you see an AIM window peeking out from behind your browser and you click on it, that window will come to the front, but the main application window will not. The Mail.app/Activity Viewer is another example. The Aqua system of layers works well in many instances, but not in all. Thank goodness that the Dock is always there to come to the rescue. I know that clicking on an application icon in the Dock will always result in not only the application coming to the front, but also any non-minimized windows associated with it. And if the application is active but no windows are open, clicking on the Dock icon should create a new window in that application.
Posted by: Lambert at January 24, 2004 8:53 PMDescribing is not knowing.
Posted by: Kolker Danielle at January 25, 2004 9:12 AM