FIR filter lookup table, HeapBlock vs AudioBuffer


Hey Jucers,

I’ve been working on FIR filter that should be suitable for frequency modulation, since calculating coefficients on-the-fly proved being way too heavy, I thought of making a coefficients lookup table.

Then enters my doubt. What would be better, allocating a bunch of AudioBuffers to hold the components, letting the AudioBuffer do the memory allocation, or allocating a single HeapBlock and assigning offsets to the AudioBuffer?

The memory allocation performance isn’t key, since it will be done out of the audio thread, the goal is to get the best read/copy performance.

I tried doing some profiling, but my results were inconclusive. Does anyone has some advice or insight with this?

Thanks a lot, :slight_smile:


Why would you expect read performance to be different for different classes having performed the memory allocation?
In the end it’s just some heap memory you access, the only difference I could imagine would be that a continuous piece of memory allocated by a single HeapBlock could better fit into one cache line, so there might be fewer cache misses. But as you are speaking of FIR coefficients I assume that those might possibly be a lot longer then one cache line - so I would assume this doesn’t matter at all.
This is my intuitive answer from my more hardware-orientated point of view. But maybe some software gurus will see a point I overlooked :wink:


Well, I know alignment plays an important part when it comes to memory performance, there’s also active and swapped pages, I’m pretty sure there’s lots differences between allocating 1 big chunk and lots of small ones, but I couldn’t get any conclusion after reading about it and looking at JUCE code.

Thanks for the input, BTW :wink:


I’ve been playing round with this a lot recently and there’s no real difference as the stride access will be the same and chosing which wether to read from an offset index in one big block or instead choosing a particular block again no real difference.

My preference is to have one big block as it’s just one element to manage over lots of smaller ones.

PS you can still do alignment even if you have an odd number of taps. Just have some redundant bytes between each offset to keep the speed up and it will still take up less memory in all.