Showing device list in kcontol almost hangs it. It may hang for 30-40 seconds ignoring any user input
Basic information
TDE version: R14.0.13
Distribution: ArchLinux with OpenRC
Hardware: amd64
Description
Every time it requests unique device it calling TDEHardwareDevices::listAllPhysicalDevices(), which is very slow.
#0 0x00007ffff61781d3 in TQGList::TQGList(TQGList const&) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#1 0x00007ffff6872072 in TDEHardwareDevices::listAllPhysicalDevices() () from /opt/trinity/lib/libtdecore.so.14
#2 0x00007ffff6872584 in TDEHardwareDevices::findByUniqueID(TQString) () from /opt/trinity/lib/libtdecore.so.14
#3 0x00007ffff41f1070 in TDEHWManager::deviceChanged(TDEGenericDevice*) () from /opt/trinity/lib/trinity/kcm_hwmanager.so
#4 0x00007ffff41f2262 in TDEHWManager::tqt_invoke(int, TQUObject*) () from /opt/trinity/lib/trinity/kcm_hwmanager.so
#5 0x00007ffff5f012f6 in TQObject::activate_signal(TQConnectionList*, TQUObject*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#6 0x00007ffff6872974 in TDEHardwareDevices::hardwareUpdated(TDEGenericDevice*) () from /opt/trinity/lib/libtdecore.so.14
#7 0x00007ffff687b0cf in TDEHardwareDevices::processModifiedCPUs() () from /opt/trinity/lib/libtdecore.so.14
#8 0x00007ffff688fbc9 in TDEHardwareDevices::tqt_invoke(int, TQUObject*) () from /opt/trinity/lib/libtdecore.so.14
#9 0x00007ffff5f0165c in TQObject::activate_signal(TQConnectionList*, TQUObject*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#10 0x00007ffff5f01802 in TQObject::activate_signal(int) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#11 0x00007ffff5f24d0a in TQTimer::event(TQEvent*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#12 0x00007ffff5ea69d9 in TQApplication::internalNotify(TQObject*, TQEvent*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#13 0x00007ffff5e9cb96 in TQEventLoop::activateTimers() () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#14 0x00007ffff5e86f67 in TQEventLoop::gsourceDispatch(_GSource*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
Sometimes gdb gets it stopped in string functions called from TQGList constructor
Steps to reproduce
Open kcontrol hardware manager
Select some device properties if it stil not hang, it will request another device id and wait 1-2 minutes until it show information
Showing device list in kcontol almost hangs it. It may hang for 30-40 seconds ignoring any user input
## Basic information
- TDE version: R14.0.13
- Distribution: ArchLinux with OpenRC
- Hardware: amd64
## Description
Every time it requests unique device it calling TDEHardwareDevices::listAllPhysicalDevices(), which is very slow.
```
#0 0x00007ffff61781d3 in TQGList::TQGList(TQGList const&) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#1 0x00007ffff6872072 in TDEHardwareDevices::listAllPhysicalDevices() () from /opt/trinity/lib/libtdecore.so.14
#2 0x00007ffff6872584 in TDEHardwareDevices::findByUniqueID(TQString) () from /opt/trinity/lib/libtdecore.so.14
#3 0x00007ffff41f1070 in TDEHWManager::deviceChanged(TDEGenericDevice*) () from /opt/trinity/lib/trinity/kcm_hwmanager.so
#4 0x00007ffff41f2262 in TDEHWManager::tqt_invoke(int, TQUObject*) () from /opt/trinity/lib/trinity/kcm_hwmanager.so
#5 0x00007ffff5f012f6 in TQObject::activate_signal(TQConnectionList*, TQUObject*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#6 0x00007ffff6872974 in TDEHardwareDevices::hardwareUpdated(TDEGenericDevice*) () from /opt/trinity/lib/libtdecore.so.14
#7 0x00007ffff687b0cf in TDEHardwareDevices::processModifiedCPUs() () from /opt/trinity/lib/libtdecore.so.14
#8 0x00007ffff688fbc9 in TDEHardwareDevices::tqt_invoke(int, TQUObject*) () from /opt/trinity/lib/libtdecore.so.14
#9 0x00007ffff5f0165c in TQObject::activate_signal(TQConnectionList*, TQUObject*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#10 0x00007ffff5f01802 in TQObject::activate_signal(int) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#11 0x00007ffff5f24d0a in TQTimer::event(TQEvent*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#12 0x00007ffff5ea69d9 in TQApplication::internalNotify(TQObject*, TQEvent*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#13 0x00007ffff5e9cb96 in TQEventLoop::activateTimers() () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
#14 0x00007ffff5e86f67 in TQEventLoop::gsourceDispatch(_GSource*) () from /opt/trinity/tqt3/lib/libtqt-mt.so.3
```
Sometimes gdb gets it stopped in string functions called from TQGList constructor
## Steps to reproduce
1. Open kcontrol hardware manager
2. Select some device properties if it stil not hang, it will request another device id and wait 1-2 minutes until it show information
That's interesting. I have used the device hardware manager a lot and it never hanged or show slowness here.
Is there any way you could profile the code and see where it gets slow?
That's interesting. I have used the device hardware manager a lot and it never hanged or show slowness here.
Is there any way you could profile the code and see where it gets slow?
The problem must be somewhere else because the [function](https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/src/commit/e13b91d5e431c2430dd4f52e297796593de99866/tdecore/tdehw/tdehardwaredevices.cpp#L4622) is returning just a copy of the list
```
TDEGenericHardwareList TDEHardwareDevices::listAllPhysicalDevices() {
TDEGenericHardwareList ret = m_deviceList;
ret.setAutoDelete(false);
return ret;
}
```
Copying list every time when need to find ID in it is not very good idea, maybe need return reference?
Of cause performance is depended on device list count, which seems to be very large it my case.
And deviceChanged seems to be called to oftenly
Copying list every time when need to find ID in it is not very good idea, maybe need return reference?
Of cause performance is depended on device list count, which seems to be very large it my case.
And deviceChanged seems to be called to oftenly
That's interesting. I have used the device hardware manager a lot and it never hanged or show slowness here.
Is there any way you could profile the code and see where it gets slow?
It is not clear who you are asking. I can try, but can not promise fast result, I have not much time recently.
I tried in a VM and this is working there with no lagging. The VM is on the same PC, so it can not be the performance of the PC.
Indeed we'll have to find the one that is causing this.
> That's interesting. I have used the device hardware manager a lot and it never hanged or show slowness here.
> Is there any way you could profile the code and see where it gets slow?
It is not clear who you are asking. I can try, but can not promise fast result, I have not much time recently.
I tried in a VM and this is working there with no lagging. The VM is on the same PC, so it can not be the performance of the PC.
Indeed we'll have to find the one that is causing this.
I tried in a VM and this is working there with no lagging.
That is also interesting because my system is also running in a VM. If I have time, I will update an old computer and see if I can see the same problem there.
> It is not clear who you are asking.
Anyone who can reproduce the problem :-)
>I tried in a VM and this is working there with no lagging.
That is also interesting because my system is also running in a VM. If I have time, I will update an old computer and see if I can see the same problem there.
Copying list every time when need to find ID in it is not very good idea, maybe need return reference?
I just double checked, TDEGenericHardwareList is a TQPtrList, not a TQValueList, so it could be part of the reason in case the copy happens often and the list if very long. TQValueList is implicitly shared, but TQPtrList is not, so the copy won't take O(1).
> Copying list every time when need to find ID in it is not very good idea, maybe need return reference?
I just double checked, TDEGenericHardwareList is a TQPtrList, not a TQValueList, so it could be part of the reason in case the copy happens often and the list if very long. TQValueList is implicitly shared, but TQPtrList is not, so the copy won't take O(1).
This issue got closed automatically when TDE/tdebase#312 was merged.
Before closing for real, I want to confirm that the slowness is no longer experienced in old computers.
This issue got closed automatically when TDE/tdebase#312 was merged.
Before closing for real, I want to confirm that the slowness is no longer experienced in old computers.
Showing device list in kcontol almost hangs it. It may hang for 30-40 seconds ignoring any user input
Basic information
Description
Every time it requests unique device it calling TDEHardwareDevices::listAllPhysicalDevices(), which is very slow.
Sometimes gdb gets it stopped in string functions called from TQGList constructor
Steps to reproduce
Have you tried with R14.1.0-dev? Seems to work well here, no delays.
indeed it takes a lot of time - the lag is evident.
That's interesting. I have used the device hardware manager a lot and it never hanged or show slowness here.
Is there any way you could profile the code and see where it gets slow?
The problem must be somewhere else because the function is returning just a copy of the list
Copying list every time when need to find ID in it is not very good idea, maybe need return reference?
Of cause performance is depended on device list count, which seems to be very large it my case.
And deviceChanged seems to be called to oftenly
It is not clear who you are asking. I can try, but can not promise fast result, I have not much time recently.
I tried in a VM and this is working there with no lagging. The VM is on the same PC, so it can not be the performance of the PC.
Indeed we'll have to find the one that is causing this.
Anyone who can reproduce the problem :-)
That is also interesting because my system is also running in a VM. If I have time, I will update an old computer and see if I can see the same problem there.
I just double checked, TDEGenericHardwareList is a TQPtrList, not a TQValueList, so it could be part of the reason in case the copy happens often and the list if very long. TQValueList is implicitly shared, but TQPtrList is not, so the copy won't take O(1).
I tested on an old computer with native TDE installed. I can reproduce the issue with R14.1.0-dev code.
Indeed the problem is with the handling of the device list throughout tdehw lib. Will need to change a few things to get this fixed.
This issue got closed automatically when TDE/tdebase#312 was merged.
Before closing for real, I want to confirm that the slowness is no longer experienced in old computers.
Checked on a 2011 i386 computer and the slow behavior is gone, so confirming the issue as closed.