On Saturday 09 February 2008 04:50, Manish Chakravarty wrote: > On Feb 9, 2008 1:30 AM, Adriaan de Groot <groot at kde.org> wrote: > > On Friday 08 February 2008 19:47, Manish Chakravarty wrote: > > > As a starting point, I want to do dynamic tracing of this application. > > > Though this app is relatively small, it demonstrates the power of Qt's > > > > I don't see the connection here between dtrace and the Qt meta-object > > system. > > As a starting point, I want to be able to probe what is going on behind the > scenes when meta object calls are made ( and how efficient they are, > getting an idea of their time complexity, etc )
Aha. That's an excellent something to look into. There are a lot of table lookups involved and -- if I remember correctly -- string comparisons to be made along with signal / slot name normalization. > Let's say you there is a KDE4 or Qt4 app whose UI has been designed using > the Qt Designer. > The XML .ui file is being read at run time to draw widgets and make > signal-slot connections > > I know from experience that is not as efficient as drawing the UI by hand. > But how do i quantify it? I attach a probe to the QObjects that are being > instantiated at run-time. I would have an idea! The only reason I can come up with for "less efficient" is that you get more layouts and boxing in designer-generated code; there is the same one-off object creation (and of course many .ui files are translated to C++ at compile time and not handled at run time at all). So again, this would be very interesting to quantify (at the same time, you could possibly walk the Qt object tree at runtime to do the same kind of discovery instead of going through DTrace). > Another example: I have heard that Qt is leaking memory on Solaris ( at > least the way Qt is being built by the KDE/Solaris project) > Where exactly is it leaking memory and why? QObject has (rudimentary) > garbage collection. Why is gc not happening properly? QObject doesn't garbage collect, it destroys its children in the destructor. There are many other ways to leak memory than forgetting to destroy QObjects, don't forget. In Qt 4.3.2 and .3 there were specific OpenGL leaks (which Thiago tells me are fixed in .4). > DTrace would provide answers. In fact > http://developers.sun.com/solaris/articles/dtrace_cc.html demonstrates how > to catch memory leak problems in C++ apps. We need to make it more > Qt-specific ( by writing probes to the classes i mentioned in my original > mail ) to get a better idea, That's an excellent idea. Don't get me wrong, I wholeheartedly support the creation of DTrace probes for Qt and KDE specifics -- something that is entirely beyond my technical prowess. My concern is about focusing on, somehow, the "right" problems. [ade]
