u[i:i] or view(u, i:i) create a one element array/view, so the u in shift_and_compute1 and compute1 always has length 1. I changed those functions to take a scalar instead of an array and got about a 6 to 9x speed up.
Also, you can get rid of most of the type annotations without affecting the performance. The only ones you need are in compute and compute1 functions, because the types are used in those functions. You could alternatively get the types with eltype(f.in) for example and drop those too. My version is here: https://gist.github.com/lendle/897eea1e5458eedb8e43. On Thursday, July 31, 2014 10:10:13 AM UTC-7, Neal Becker wrote: > > Daniel Jones wrote: > > > > > Here's a version that's 7x faster (and almost 8x if you disable bounds > > checking). The main thing is to avoid indexing into arrays with ranges > (as > > in u[i:j]) if you can, since that will allocate and copy a new array > each > > time. And also, like Patrick said, globals should usually be declared > with > > 'const'. > > > > On Thursday, July 31, 2014 8:38:33 AM UTC-7, Neal Becker wrote: > >> > >> Attached is my 1st attempt at julia, it is a simple FIR filter, which I > >> translated from my c++ version. > >> > >> It is benchmarking about 10x slower than python wrapped c++ version. > >> > >> Any suggestions? > > I was concerned about that indexing arrays causing copying, and to get > closer to > the c++ version (which does not copy), I tried out ArrayViews. I'll > attach that > version, but I did not see any speedup.
