On Mon, Nov 1, 2010 at 2:28 PM, Lukáš Tinkl <lti...@redhat.com> wrote: > Dne Po 1. listopadu 2010 18:25:33 Dawit A napsal(a): >> On Mon, Nov 1, 2010 at 10:19 AM, Lukáš Tinkl <lti...@redhat.com> wrote: >> > Dne Ne 31. října 2010 03:32:52 Dawit A napsal(a): >> >> On Wed, Oct 27, 2010 at 12:24 PM, Dawit A <ada...@kde.org> wrote: >> >> > On Wed, Oct 27, 2010 at 7:48 AM, Lukáš Tinkl <lti...@redhat.com> wrote: >> >> >> Dne St 27. října 2010 00:57:27 Christophe Giboudeaux napsal(a): >> >> >>> Hi, >> >> >>> >> >> >>> Le 27/10/2010 00:20, Dawit A a écrit : >> >> >>> > Does anyone have a problem opening project files (CTRL+O) in >> >> >>> > qtcreator 2.0.1 (Qt 4.7) with the current trunk version of kdelibs >> >> >>> > ? >> >> >>> > >> >> >>> > For me the minute I try to open a project, the screen flashes as >> >> >>> > if to paint the file dialog and then qtcreator completely >> >> >>> > freezes. Using gdb (backtrace) I see that the issue seems to >> >> >>> > occur when the file dialog attempts to find Places information >> >> >>> > through Solid. Solid in turn queries udisks (no hal on my system) >> >> >>> > through dbus to retrieve information about each of the several >> >> >>> > devices available on my machine and takes a very very very long >> >> >>> > time (many minutes) to do it. Any insight I can get into this >> >> >>> > would be helpful before I waste even more time to try and find >> >> >>> > out what could possibly be causing this issue for me... >> >> >>> >> >> >>> See https://bugs.kde.org/show_bug.cgi?id=253039 >> >> >> >> >> >> Strangely enough it happens only in non-KDE aplications anb i can't >> >> >> reproduce it... (not running HAL on my Fedora either); for me the >> >> >> open dialog in eg. Qt Creator shows immediately. >> >> > >> >> > I am not running HAL on my system either. In fact hal is not even >> >> > installed at all. And the freeze happens for non-KDE apps only as >> >> > mentioned above. I was able to reproduce the problem with QtCreator >> >> > and VLC so far. I have added a comment on the bug report given above >> >> > with backtrace information from QtCreator... >> >> >> >> On my system commenting out the attempt to prefill the cache in >> >> UDisksManager's ctor solves the problem. I really do not see the >> >> beneift of doing that in the ctor anyhow... >> >> >> >> Regards, >> >> Dawit A. >> > >> > You are probably right, this was made in an attempt to speed up things >> > but it turned out the problem had been somewhere else (in the device >> > properties cache). I will remove it, please retest as I am not getting >> > those problems you mentioned. >> >> You reverted back your commit though... Did it break something ? >> Anyhow, for me it solved the noticeble lags in KDE apps and the very >> very long delays in QtCreator. However, the issue of the very very >> long delays in VLC still persist even after removing that line... > > Well it essentially broke things, so I reverted it :) you can check with > solid-hardware details <udi>
That is easy enough to address since it is caused by m_deviceCache not being populated before it is use. BTW, the temporary result variable in allDevices is completely unnecessary. Since it simply ends up being assigned to m_deviceCache at the end, why not use m_deviceCache in the first place and avoid unecessary copies ? Anyways, attached is a patch that should fix the solid-hardware issue as well as cleanup the allDevices function...
solid_udisks_udisksmanager.patch
Description: Binary data