perf: skip numpy array creation in _compute_fwd_scale scalar path

[intel-python-devops]

Note

This pull request is entirely AI-generated. Please review thoroughly.

• mkl_fft/_fft_utils.py: in _compute_fwd_scale, short-circuit np.prod when the size argument is a plain scalar (int or np.integer) — the case used by every 1-D call (fft, ifft, rfft, irfft) — instead of always routing the scalar through np.prod, which allocates and reduces a 0-d numpy array on every call. N-D callers (_nd_fwd_scale, which always passes a resolved list/sequence) are unaffected and still use np.prod.

_compute_fwd_scale runs on every mkl_fft.fft/ifft/rfft/irfft call regardless of norm, and for the scalar 1-D case np.prod(scalar) does nothing but wrap and unwrap a 0-d ndarray, so avoiding it removes pure per-call Python/NumPy overhead on the hottest, smallest-transform code path without changing the computed scale value or its numeric type usage downstream (both python int/float and numpy scalar values convert identically into the Cython double fsc parameter).

[antonwolfy]

I have a couple of nits, but in overall LGTM.
The PR add few lines of code but reduce memory consumption avoiding temporary np.ndarray allocation.

[antonwolfy]

Can we have tighter comment here?

Suggested change

	# `np.prod` dominates the Python-side cost of a small normalized transform,
	# so take cheaper routes for the two shapes the callers actually pass: a
	# scalar `n` (1-D) and a sequence (`_nd_fwd_scale`). It stays the fallback
	# because `numpy.fft` also accepts array-like `n` and `s` (e.g. a 0-d
	# `n=np.array(8)`, a 1-D `s=np.array([4, 4])`), which `math.prod` cannot
	# handle uniformly.
	# Avoid np.prod's 0-d-array overhead on the hot scalar (1-D) and sequence
	# (N-D) paths; np.prod stays as the fallback for array-like `n`/`s`
	# (e.g. np.array(8)) that math.prod can't handle.

[antonwolfy]

Could you please populate the changelog?