February 6, 2003

Cache

OK, so Minimo is getting us pretty small. 8-9M codesize, 13M first-page startup and around 22-24M high watermark. This is even with the lea allocator, which according to waterson takes fragmentation to a minimum (it saves us a little under a meg of maxheap as far as we can tell). So the numbers I posted before for mfcembed weren't the best representation of the goal we have to hit for embedded systems (certainly a big deal, but not the main goal). it is our static growth that is the problem. We fit fine on embedding platforms. And it's not leaks, or at least not much; this goes up and levels off (as others have pointed out before). This is cached data (not necessarily the cache), most of it at least. I am certain there are leaks, but the cache problem is a prerequisite to deal with any of that.

This entry is a reminder to myself of stuff to do to the minimo branch:

  1. Get rid of XSLT bindings (make a switch to not create the XSL content sink and friends). This seems to be pretty low-hanging fruit; XMLContentSink is the only place in the app where we talk to XSLT.
  2. Don't include printing and plugin DLLs in the "small embedder" solution
  3. Hook into low memory pressure sensor to gc, compress frame arena (possible?), get rid of any cached images and documents and basically destroy anything else that we're caching. For embedders, run this algorithm after every page too, to keep memory down.
  4. Turn off paint suppression entirely and ensure that we therefore don't have two docs in memory at the same time
  5. Turn off frame arena and see if that keeps our maxheap down. Not even sure if this will work, let alone keep maxheap down.
Posted by jkeiser at February 6, 2003 12:18 PM
Comments

By 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: Hercules at January 26, 2004 1:50 AM

For my Paint application, I created a series of icons to simulate a rendering algorithm. While the application is performing this CPU-intensive task, you can always see the status of the document by the icon changing in the Dock.

Posted by: Howell at January 26, 2004 1:50 AM

Other examples of these animations might be to show the status of an FTP transfer, the progress of media being digitized, or an updated time signature. And don't forget that users may want to have some control over this, so give them plenty of options, including the ability to turn these functions off.

Posted by: Bennett at January 26, 2004 1:50 AM

Not 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: George at January 26, 2004 1:50 AM

So 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: Augustine at January 26, 2004 1:51 AM

If 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: Watkin at January 26, 2004 1:51 AM

By 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: Anchor at January 26, 2004 1:51 AM

Adhere to System Appearance. Does your application use all the sweetly colored buttons, delightfully shaded windows, and all the other "bells and whistles?"

Posted by: Alveredus at January 26, 2004 1:51 AM

Adopt Sheets. I really like the use of Sheets in OS X. The use of Sheets lets me know which window my dialogue belongs to without hijacking my system.

Posted by: Janikin at January 26, 2004 1:51 AM

Dock Animation. Sometimes animating icons in the dock can be useful in communicating the status of the system or application.

Posted by: Bertram at January 26, 2004 1:52 AM