GNOME Bugzilla – Bug 213207
compose (message) window takes forever to open
Last modified: 2003-04-05 20:15:38 UTC
Package: Evolution Priority: Normal Version: 0.15 Synopsis: compose (message) window takes forever to open Bugzilla-Product: Evolution Bugzilla-Component: Mailer Description: on both my computers, evolution runs somewhat slow.... however, the compose window takes especially long to open. Can anything be done to speed this up? If nothing else, maybe preopen a hidden compose window then just show it when you ask to compose a message? Unknown reporter: kliermanm@bigfoot.com, changed to bugbuddy-import@ximian.com.
Something really good to look at for 1.1/1.2 if possible.
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
1) this is gtkhtml suckage, isn't it. 2) Is there any way we can profile this in a 1.2 timeframe? It's probably the worst user interaction performance issue we have.
actually no, this is bonobo issue.
Whether or not it's bonobo it's bad and ought to be looked at.
It is almost certainly bonobo. On irc you were saying it got slower recently, if that is true can you give us a time frame? Hmmm I did add a lot of menu items at some point, that probably made it worse. About the only thing I can think of to make it seem faster is make evo start a composer an start time and keep it hidden. Then when the user clicks it should be faster. But that is really sick. Really really sick.
Unfortunately, I don't recall a date. :( And ettore suggested in the meeting that it could have been related to more bonobo stuff starting up without a bonobo change (I don't think he mentioned menus, but that may have been what he was referring too.) So... ugh. I'd like to leave this on the 1.2 radar for the time being because it is the most glaring performance issue we have left. If we can't solve it, we should at least have a whirly icon or message in the status bar to indicate work is being done.
*** bug 214694 has been marked as a duplicate of this bug. ***
Well it's relatively possible to speed the thing up. I imagine the problem is that each time we re-exec gtkhtml, so one pragmatic way to do this is to keep a copy of gtkhtml in the background that you arn't using - that will speed up new window creation. Another way to do it is to hold a reference on the factory - sadly in Gnome 1.4 that's not so easy to do. Yet another way is to ensure that the gtkhtml component doesn't quit and de-register when it looses it's last window, but instead waits for (perhaps a minute) and then de-registers itself. That should provide a nice speedup with no (vicious) lifecycle ramifications.
This should be almost fixed with the latest Bonobo. Removing the "feature" keyword.
i just installed bonobo 1.0.19 and am not seeing an improvement.... is this the version you are refering to, or a CVS version?
Hi Lad, I think Ettore is wrong - most of the existing slowness with opening gtkhtml is most likely activation overhead - execing the process and then when you've composed your mail and do a new one re-execing a new process - very wasteful. As suggested above we need to hold a reference on something and have a timeout.
The editor is now a shlib by default and composer startup is pretty fast, closing this bug.