I think this is one of those things that’s pretty field-specific. For instance I’m generally not convolving with filters that are small enough for the direct implementation to be efficient. As you mention, for similarly-sized inputs the FFT approach is generally better, and when they are very differently-sized you want to use overlap-save convolution, which uses FFTs in a block-wise fashion. The conv implementation currently selects between those two algorithms depending on the size of the input, but it would be good for it to also select the direct method when one of the inputs is small enough.
Basically it’s a matter of perspective - some folks say “FFT convolution is only useful for really big inputs” and other say “direct convolution is only useful for really small inputs”. Seems like conv could be smart enough to always do the right thing, but someone needs to add that check.
I agree the docs could be improved. I usually expect the convolution of a length-N array and a length-M array to be length N+M-1, but that should be documented.
Though it uses the FFT algorithm, DSP.jl’s conv implementation takes care of zero-padding internally, so it does linear convolution, not circular convolution.
To answer the original question, it seems that what you want depends on the characteristics of your filter b. First off, I’m assuming that the idea is for the output to “line up” with the input. If the filter peaks on the first sample (like exp.(0:-0.5:-10)), then you probably want something like conv(a, b)[1:length(a)]. But if you have some filter that includes a delay, like gaussian(21, 0.15), then you might want conv(a,b)[11:end-10].