Naive convolution takes time proportional to the number of input samples multiplied by the length of the reverb impulse response (kernel), which becomes rather

Naive convolution takes time proportional to the number of input samples multiplied by the length of the reverb impulse response (kernel), which becomes rather impractical for seconds-long reverb tails with >100k samples, convolved by ~50k samples per second. The usual solution is overlap-{add/discard} block convolution, where computational power decreases as the amount of input data processed at once increases (to a degree). But if you want short latency, you must process input data in small chunks, which increases CPU load. I think the trick of block convolution is to convolve the beginning of the reverb kernel in small chunks, and the later portions in large chunks (buffering small chunks of input into large chunks, convolving large chunks once available, and playing the result back in small chunks), and adding the two reverb tails (though I haven't fully studied or tried implementing it myself, and IIRC it's patented anyway).