Bug #1909
Extremely slow on Windows when doing more than one thing at once
Status: | Closed | Start date: | 2019-09-06 | |
---|---|---|---|---|
Priority: | Urgent | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | - |
Description
On Windows:
- Load a number of substantial audio files
- While alignment is in progress, switch to Melodic Spectrogram view
- Observe that the window updates extremely slowly, and the application enters "not responding" state for long periods of time
I think the application is still working and will eventually complete the job, but I haven't the patience to find out.
There is no such problem on Linux, and I don't think there was such a bad problem on Windows either until quite recently.
History
#1 Updated by Chris Cannam over 4 years ago
Possible candidates:
- Some lock contention problem in
c++11-mutex
branch ofvamp-plugin-sdk
- Excess locking on file access
- Lack of optimisation for
ById
logic
?
#2 Updated by Chris Cannam over 4 years ago
The origin of this appears to be that this machine is the only one I'm testing on on which enough free memory is reported for SpectrogramLayer
to make a decision to use the whole-model cache. Disabling that and using either the default 8-column cache or the finer 4-column one makes things much faster (the 8-column cache especially).
#3 Updated by Chris Cannam over 4 years ago
What is particularly problematic is "cascading" caches - generating one cache based on summaries of another cache which also needs to be filled. The whole-model cache and the normal cache were set up in this way (normal cache generated from whole-model cache). This causes massive memory pressure. Switching the normal cache to be generated directly from the FFT model essentially solves the problem.
I'm still uncertain whether the whole-model cache is useful in any circumstance.
#4 Updated by Chris Cannam over 4 years ago
- Status changed from New to Closed
Also reduced cache sizes using the new verticallyFixed
mode in SpectrogramLayer
and FFTModel::setMaximumFrequency
. With this change I think it is reasonable to leave the whole-model cache enabled.