Warning: The content of this article may be out of date. It was imported from mozilla.org and last updated in 2003.
Seth Spitzer (sspitzer@mozilla.org)
What is the "cached" compose window?
Instead of destroying the mail compose window on send (or close) just to create a new one the next time, Mozilla Mail will "cache" the compose window on send (or close), and use that instead. The downsides are that we have had some bugs, it complicates and bloats the code, and it requires more testing. The upside is that is has been a major performance win
Why did you do this?
Back 0.9.7, we hit a wall with the compose window. Any new window performance problems that mozilla has are especially painful in mail compose, as we need to create a new compose window on every new mail message or reply.
But we noticed that the common usage pattern is to compose, send, compose, send, compose send. We decided it would be worth the trouble to cache the compose window. If the user has this usage pattern, we wouldn't have to create a new window. We could just hide it on send, and then show it on the next compose. If the user opens (but never sends or closes compose windows), this trick will not apply to them. But this is not a common usage model.
How do I test it?
On window and mac, the cached compose window is on by default. To test it
- start mozilla
- do new message. this is a new compose window. notice how long it took.
- close or send the window. (the compose window is now cached)
- do new message again. this is the cached compose window. it should have been faster than in step 2.
- close or send the window. (the compose window is cached again)
- do new message again. this is the cached compose window. it should be as fast as in step 4.
- do new message again. there is no "cached" window, so this will be as slow as step 4.
- close one of the compose windows. (this window is now cached).
- close the other compose window. (this window is not cached, since you already have a cached compose window.)
- do new message again. this is the cached compose window. it should be as fast as in step 4.
- do new message again. there is no "cached" window, so this will be as slow as step 4.
We cache at most <n> html compose windws and <n> plain text windows, where n is the value of the hidden pref.
What's the hidden pref to control it?
user_pref("mail.compose.max_recycled_windows", 1);
Where can I read more about it?
See