https://bugs.kde.org/show_bug.cgi?id=487459
Bug ID: 487459
Summary: Default exe priority set too high for find duplicates
process.
Classification: Applications
Product: digikam
Version: 8.4.0
Platform: Compiled Sources
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Searches-Similarity
Assignee: digikam-bugs-n...@kde.org
Reporter: carbonwer...@hotmail.com
Target Milestone: ---
***
If you're not sure this is actually a bug, instead post about it at
https://discuss.kde.org
If you're reporting a crash, attach a backtrace with debug symbols; see
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***
SUMMARY
At least in Windows, via code the app priority is set. In this case, the setup
effectively locks Windows because even at 'normal' priority, the app's priority
does not play well with core system processes. Yes, you can manually set the
.exe priority to low, and that allows for more normal operation, but this is
not persistent, and it is difficult to do with the OS nearly frozen.
STEPS TO REPRODUCE
1. Generically, run the Find Duplicates function via the GUI on a large
dataset- something that may take minutes+
OBSERVED RESULT
Windows10/11 becomes effectively inoperative, and is very slow to respond to
requests (i.e. 10 seconds from right click on task bar to a menu presentation,
on a 4ghz 8-core 64GB machine).
EXPECTED RESULT
App should not block core OS response to low-level calls (i.e. right click on
menu bar to allow access to task manager)
SOFTWARE/OS VERSIONS
Windows: 10
macOS:
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
The system works fine if the exe is set to low priority- it will still use all
the CPU that is free, but still allow other apps to be opened etc, where things
are a bit slower, but still very usable. It is difficult in Windows to script
out a change in exe priority, and its possible the process in question is
spawned as a new process/thread (i.e. maybe this is actually SQLLite, but the
process reporting the utilization is digiKam.exe). So, probably best to set the
exe priority in code. Setting default priority to low doesnt impact digiKam
except to the extent the user is running another application that is heavy on
resources. In that case, a slowdown is expected. In no case should an
application effectively stop the OS from responding to user requests and
control inputs, where that can be effectively the same as an OS freeze- at
least for the duration of the operation.
--
You are receiving this mail because:
You are watching all bug changes.
