After merging #21127, planning a FFT takes much longer

[giordano]

After merging #21127, there is a large performance regression when planning a FFT, this is particularly evident with the slow FFTW.MEASURE flag.

On commit d694548 (parent of the merge commit):

julia> FFTW.set_num_threads(4)

julia> v = Vector{Complex{Float64}}(nextpow2(100000));

julia> @time plan_fft(v, flags = FFTW.MEASURE);
  3.354884 seconds (334.41 k allocations: 17.760 MiB, 0.19% gc time)

julia> v = Vector{Complex{Float64}}(nextpow2(400000));

julia> @time plan_fft(v, flags = FFTW.MEASURE);
  2.556090 seconds (334.40 k allocations: 23.737 MiB, 0.23% gc time)

On commit 0b8c5ed (merge commit of #21127):

julia> FFTW.set_num_threads(4)

julia> v = Vector{Complex{Float64}}(nextpow2(100000));

julia> @time plan_fft(v, flags = FFTW.MEASURE);
 38.807557 seconds (334.40 k allocations: 17.735 MiB, 0.02% gc time)

julia> v = Vector{Complex{Float64}}(nextpow2(400000));

julia> @time plan_fft(v, flags = FFTW.MEASURE);
210.785749 seconds (380 allocations: 8.021 MiB, 0.01% gc time)

[stevengj]

What's actually happening is that, after #21127, threads are not being used at all. This slows down the planner because there are more non-threaded plan possibilities than there are threaded-plan possibilities.

My bad, #21127 was the wrong solution and should be reverted/fixed.

[stevengj]

I'll submit a new PR soon.