There you can see that the initialized rt_filter.py estimation took ~6 ms while the mne.filter.filter_data took ~31 ms. Both is based on a sampling frequency of 500 Hz and 6 channels.

I would much rather speed up mne.filter.filter_data for this case rather than add a new function. It's cleaner conceptually and also will benefit more people (anyone using filter_data on similar data).

In this case I'm guessing that a direct call to scipy.signal.lfilter to do the filtering would be faster than mne.filter.filter_data, but it's worth figuring out the conditions under which each method is fastest based on FIR filter length and using lfilter or our internal overlap-add method when appropriate.

@teonbrooks Thanks a lot for the code review! I will adapt it.
@larsoner That's a good point, in my implementation it get's only faster since I am precalculating in calc_band_filters() the filters using mne.filter.create_filter.

Then I only "apply" them in a np convolution in def apply_filter(). Probably this is not an optimal implementation for mne-python, but speeds up computation for real time analysis :)

That's a good point, in my implementation it get's only faster since I am precalculating in calc_band_filters() the filters using mne.filter.create_filter.

Ahh, and we don't provide a way to pass the FIR filter directly. We do this with IIR but not FIR...

We could in theory provide some way to do this in MNE. For maximum efficiency you could even compute the FFT of the filter once, and use it with the signal. We'd have to figure out an API for it, though.

@larsoner Do you mean the iir_params keyword in mne.filter.filter_data? Also I am not sure about the FFT approach. This would also require a frequency transformed version of the data itself?

Sorry if I don't really get this. For my intuition the fast approach would be simply to do the filtering in the time domain via a convolution with the precalculated filterbank.

Alright, so I adapted some changes, simply because of the nice comments of @teonbrooks :)
I am not sure though if this should be included in mne real-time now because of the upper discussion. If so I think a module in test might make sense?
Similar to my private speed test here https://github.com/neuromodulation/py_neuromodulation/blob/main/examples/speedtests/speedtest_filter_vs_MNE.ipynb

I am not sure though if this should be included in mne real-time now because of the upper discussion.

I think for now just add a comment along the lines that "someday MNE-Python could add support for precomputed FIR filters like it does for IIR" and in the meantime a PR just using np.convolve directly is fine. You might also want to note that fftconvolve or overlap-add (MNE-Python uses the latter) will be faster in some cases so if this ends up being a bottleneck there are options for optimization.

Then this PR can just focus on getting the API right and getting it to work, and optimization / refactoring of MNE-Python can be done later if someone gets motivated to do it by performance concerns.

hey @timonmerk, I will have next week to work on the project. sorry i've run away for a while. If you want to make some final adjustment, I can then merge these and we can iterate on a faster cadence.

sorry for the delay @timonmerk. thanks!