Bug: Strangely high CPU usage #50
Comments
|
What if you click on the table header “status”? As I explained in the documentation, the progress bar shown in the table will lose its animation by default. But I manually enabled it by force repainting every 1/25 seconds. I realized that this will consume a lot of CPU time, so I then gave the user a choice to disable it by clicking on the table header |
Here is what I observed after click on
|
|
So this means that you didn't enable the animation before |
|
Can you try pausing when separating a file and see CPU usage? I’m using my phone and can’t test it myself |
pause -> CPU 1% |
|
And clicking on the header when paused? |
6% (no white light animation, just green bar) It's a little tricky as enabling the animation result in a higher GPU occupacy (better). |
|
I guess this is related to QTableWidget but I can’t prove it now |
what if we cut the files passed to the GUI into chunks of 10 - 50 files, and working on each file chunk one by one? That might be a little easier to implement since it doesn't change the UI but file handling XD. |
|
Sorry but I didn't quite understand what you mean |
Actually It is quite simple. Instead of we do Just adding a second level queue (only display numbers, store in a python list or queue）would solve this issue. And for users who pass less than 50 (n) files to GUI, there won't be any change It is mostly a patch-like approach |
|
New Update: The problem can be partially solved by selecting any tab other than But the high CPU usage issue remains. |
|
That's strange. I remember that Qt renders its window CPU-only, while separation and window rendering is in different threads, so theoretically they won't affect each other... |
Here is a quick analysis from AI, actually I partially agree with it. Instead of having the GPU thread to send signal to window thread, it might be better for the window thread to request status on GPU thread, or having another one in between that is guaranteed to be non-blocking. I have not been working on thread programming for a while, but I remember a trick and just access this param from window thread, which should be non-blocking in most cases. (Below From AI) Based on the provided code, it appears that the separation process and the GUI are already running on separate threads. The However, there are a few places where the GUI thread may potentially block the GPU processing thread:
To minimize the chances of the GUI thread blocking the GPU processing thread, you can consider the following:
It's important to note that the provided code snippets don't include the complete implementation of all the methods and classes involved, so there might be other places where the GUI thread and the separation thread interact that are not visible in the given code. To fully diagnose and resolve the issue, it would be helpful to have access to the complete codebase and perform thorough testing and profiling to identify the specific points where the GUI thread may be blocking the GPU processing thread. |
|
Updating progress or UI must be done in the main thread, and I made sure that during this process, the thread called those functions must be blocked so the main thread won't be queued with a lot of callbacks... |
Yeah I agree. Actually the best way to handle lot of audio files is using a custom Dataset object and manually handle batch in -> batch out -> save to audio, but the Demucs project is a little bit too complex and containing many code integrations, which make the function a little bit hard to implement. And as it will only take about 30% speed up but requires lot of time to implement, I will just stick with GUI for now XD (the Cli is even a little slower than GUI) |
|
I'll consider adding a warning in the next version when the user adds too many files to the queue (like the first time it reaches 500) and tell what to do |
|
Lots of us out here ripping huge libraries! Any efforts to mitigate the slowdown would be ever appreciated! |
happen
It happens during the whole separation process (not just loading and saving phrase)
It' very likely caused by the gui
I am highly suspicious on the queue management as the performance get worse when queue is larger - the degradation is almost linear
What is the platform you are using?
Windows
log
The text was updated successfully, but these errors were encountered: