Today was a day of bloat. First off, taking some of the new options off the Minimo Tinderbox decreased the build zip size from 10M to 7M! That's awesome. My --disable-xslt-bindings patch only shaves 20K off TestGtkEmbed in a rigorously optimized build. Though as sicking pointed out there is still more to shave with XPath.
I did get useful trace-malloc data today (only after a highly painful time writing demangling scripts and massaging types.dat to fit the New World). One idea that might come out of this (might!) is to deliberately remove some StringBundles from memory after each page, or at least when we approach the hard limit.
One serious question is why we have nsSHEntries in the embedding build. They account for a decent portion of memory. Another is why void*'s are not all accounted for in uncategorized.pl.
Metrics I want to do now:
- find out who owns the leaked / cached objects (might just be doable looking at the memory dump from trace-malloc)
- determine what types of objects increase as we go through the pageload tests
- find all hashtables, arenas and arrays that persist through multiple pages, and force their owners to give up the memory
This 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: Hansse at January 24, 2004 7:56 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: Godfrey at January 24, 2004 7:56 PMUser Assistance. This is helping the user with the proper "next step" when performing a task. Less guesswork for the user on what to do next makes for a better experience.
Posted by: Court at January 24, 2004 7:56 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: Joan at January 24, 2004 7:56 PMBut limit your animations to whatever is required to communicate the necessary information. Avoid annoying animations that discourage ease of use. Ask yourself, "What do I need to show the user, and what is the cleanest way possible to achieve that?" A good example is the Mail application for Mac OS X. Whenever a new message arrives, the Dock icon changes appearance to indicate a changed state.
Posted by: Edith at January 24, 2004 7:56 PMDock Animation. Sometimes animating icons in the dock can be useful in communicating the status of the system or application.
Posted by: Hercules at January 24, 2004 7:56 PMNot quite as entertaining as Shrek, but Dock animation can be an important and useful function in your application. For example, Dock animation is a helpful way to indicate the status of your application.
Posted by: Adam at January 24, 2004 7:56 PMThis is the first thing your users see, and probably the single most important visible part of your application. It is the first chance you have at making an impression and the best chance to help establish your brand.
Posted by: Manasses at January 24, 2004 7:56 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: Albert at January 24, 2004 7:56 PMUser Assistance. This is helping the user with the proper "next step" when performing a task. Less guesswork for the user on what to do next makes for a better experience.
Posted by: Morgan at January 24, 2004 7:56 PM