Bug #1909

Extremely slow on Windows when doing more than one thing at once

Added by Chris Cannam 12 days ago. Updated 6 days ago.

Status:ClosedStart date:2019-09-06
Priority:UrgentDue 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 12 days ago

Possible candidates:

  • Some lock contention problem in c++11-mutex branch of vamp-plugin-sdk
  • Excess locking on file access
  • Lack of optimisation for ById logic

?

#2 Updated by Chris Cannam 7 days 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 7 days 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 6 days 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.

Also available in: Atom PDF