As far as I can tell, the only thing that's changed is #5399, which removes the gil from the core loop of rank filters. I can imagine that this adds a small overhead when running single threaded in some situations, e.g. maybe releasing and reacquiring the gil is more expensive on Windows? However, the change results in very significant (multi-x) speedups in multithreaded environments, so I'm not sure whether much can be done here... (ie we are not going to revert #5399.) Perhaps @soyers you can try to benefit from the multithreading improvements using skimage.util.apply_parallel to offset the 30% slowdown you're seeing?

@scikit-image/core unless others have ideas about how to fix this, I suggest (unfortunately!) closing this as wont-fix...

@soyers do you have any thoughts on the above? I'm disappointed to not be able to help but I don't see another way forward...

It would be really useful to know how many cores were available to the Win10 (virtual?) environment in question @soyers.

Beyond the code changes, did anything get tweaked globally in how Windows builds are compiled and optimized around 0.18? It's been a while, though, and I would have expected lots more complaints since if there was something systematic going on, especially with nogil. The number of single-threaded Windows users may be so small as to allow it to fly under the radar.

@JDWarner what do you mean by "single threaded windows users"? I would expect that most users work with single threads. I think it's more likely that most people, especially desktop users (vs HPC running Linux) wouldn't notice a 30% performance decrease.

Hi @jni and @JDWarner,

thank you for the detailed feedback and your thoughts on this!

@JDWarner I am using a Windows 10 System (native, no VM) with a (mini)conda environment. The scikit-image library is installed from the anaconda repository. The machine executing the tests is a Dell Precision 7520 with an Intel Core i7-6920HQ (4C8T) and 32GB RAM. The experiment above is not parallelized (runs on a single core).

I am currently struggling to understand which version of scikit-image actually introduced the kernels which release the GIL. #5399 was merged in May 2017 while scikit-image 0.17.2 was released in 2020. I was therefore assuming that version 0.17.2 already contains the changes for releasing the GIL. As far as I understand this commit should be the one that was released as v0.17.2: https://github.com/scikit-image/scikit-image/blob/1188c33c3defefdc0f672870b5bcc36beaec967f/skimage/filters/rank/bilateral_cy.pyx
The definition of the mean kernel (_kernel_mean) seems to already have the nogil: tag. However, this version does not show the performance regression on my machine.
Am I missing some important point here?

Using the release tags to narrow down the time frame in which the regression must have been introduced, I would argue that the following PRs most likely introduced the regression:

• 3D Rank Filters #4435
• imread() for tiff file returns wrong dimensions #5545
  My gut-feeling says that 3D Rank Filters #4435 is more likely to have introduced the regression, but I'm just guessing.

I just skimmed over the changes and noticed that this PR introduces a couple of changes in how parameters are passed to the cython part of the code. cd5c1a7#diff-11036dd1acc33e83cc65e4a480cb1eb4d56877c10ebbf93c5e5e974191d92988 shows that a lot of Py_ssize_t* turned into Py_ssize_t[::1] (unfortunately I don't have experience with this, so probably it boils down to being the same).
Also, the _core function to execute kernelse (see cd5c1a7#diff-9fce4d855510db2956d712c46bb402fd6b541fd49fa109746751bb826d0c2526) seems to hace changed the way of allocating memory.
For example:

cdef Py_ssize_t [::1] se_e_r = np.empty(se_size, dtype=np.intp)

changed to

se_e_r = <Py_ssize_t*>malloc(se_size)

Unfortunately, I don't have the knowledge to judge if some of these changes could potentially cause regressions, but mayve you have more insight concerning this topic!

I'm grateful about any input 😄

If your application allows relaxing the disk footprint to a square one of similar area (e.g. 14x14 square instead of radius=8 disk) you can get better performance using scipy.ndimage.uniform_filter. This is because the square footprint is separable across axes so it gets computed using a 14x1 rectangle and then the output of that is filtered by a 1x14 footprint. uniform_filter also uses a sliding window approach for efficiency.

a lot of Py_ssize_t* turned into Py_ssize_t[::1]

This might be related. I think sometimes Cython memoryviews can be a little slower than using pointers, but we would have to benchmark it to be sure.

@grlee77 Thank you very much for the hint! I hadn't thought about using a uniform filter.

Concerning the memoryviews vs pointers issue, I can imagine that it's hard to tell whether this is really an issue. I am not sure when I will find the time to investigate this, but if somebody else already has a development stack running and is trying to reproduce this, I will do my best to help!