On Monday, September 12, 2016 at 8:16:52 AM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Monday, September 12, 2016 at 7:59:33 AM UTC-4, DNF wrote:
>>
>> function(p::pnseq)(n,T=Int64)
>>
>>>
> Note that the real problem with this function declaration is that the type
> T is known only at runtime, not at compile-time. It would be better to
> do
>
> function (p::pnseq){T}(n, ::Type{T}=Int64)
>
Note that you have the same problem in several places, e.g. in
Constellation.jl.
(I don't really understand what that file is doing, but it seems to be
constructing lots of little arrays that would be better of constructed
implicitly as part of other data-processing operations.)
There are lots of micro-optimizations I can spot in Constellation.jl, e.g.
let k = 2*pi/N; [cis(k*x) for x in 0:N-1]; end is almost 2x faster than
[exp(im*2*pi/N*x) for x in 0:N-1] on my machine, but as usual one would
expect that the biggest benefits would arise by re-arranging you code to
avoid multiple passes over multiple arrays and instead do a single pass
over one (or zero) arrays.
(I also have no idea how well-optimized the DSP.jl FIRFilters routines are;
maybe Tim Holy knows, since he's been doing optimizing filters for
Images.jl)
