[Bug 303477] opening chat window from notifications takes too long

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=303477

David Edmundson <kde at davidedmundson.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kde at davidedmundson.co.uk

--- Comment #4 from David Edmundson <kde at davidedmundson.co.uk> ---
No to nasty hacks just now, there's still a lot we can do, and a lot of
research to be done.

George K did a valgrind analysis, result was main delays are in parts we can't
change.

I think the blame is in the factories, it's a lot of dbus calls and won't show
in valgrind. We've seen already in the CL reducing these and later calling
upgradeContacts() makes a big difference.

We can also start loading the HTML themes once the app is waiting for the
channel rather than after. There's a static call to load the themes, that we
could just move to main() or something. It's a lot of IO.

I want:
 - kDebug() << QTime().mSecsTo(QTime::currentTime()) << "starting XYZ";
littered throughout the code, when every pendingOperation starts and finished
and whilst waiting for the QWebView, between main and handle channels. Maybe
give it a differnet ID so we can turn it on/off independently.
(timing style is taken from plasma, if anyone knows of anything better please
say. Can't really use QBenchmark we depend on interaction with other apps too
much)

 - a bustle-dbus-monitor recording of this app starting up (that opens in
bustle..mine keeps crashing).
so we know how much is plasma, the approver,  MC, dbus and actually the
text-ui.

Martin, you see this issue most. If I add the debug can you run it? (or you
apachelogger)

We can't act on anything until we know where we're fixing it and why.

-- 
You are receiving this mail because:
You are the assignee for the bug.