> > The profiler can never interfere with the optimizer. It's a sampling > profiler, > so it doesn't affect code generation at all. >
I see. Then I don't get why the condition n % 2 == 0 in my if-statement would need to allocate 3 Mb of memory? The docs you've submitted suggest that type-stability might be the issue - but n::Int, and also ~1000 Int conversions can (should) hardly generate 3 Mb, so that shouldn't be a problem? I'll give the tools you recommend a try tomorrow. > Given your assumptions, you especially need to read this section carefully > (memory allocation is the "canary in the coal mine"): > > https://github.com/JuliaLang/julia/blob/b9a695669d8f8aa7648188790d3c71b6ce7effec/doc/manual/performance-tips.rst#measure-performance-with-time-and-pay-attention-to-memory-allocation > > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fblob%2Fb9a695669d8f8aa7648188790d3c71b6ce7effec%2Fdoc%2Fmanual%2Fperformance-tips.rst%23measure-performance-with-time-and-pay-attention-to-memory-allocation&sa=D&sntz=1&usg=AFQjCNHQVc9dNc42WcUTPI5X8dGxZ9BYqA> > > Just to clarify: Is the point here to avoid unnecessary allocations, or to move allocation out of the function? I.e. would M = Array(Int, n, n) magic!(M) be different from inserting M = Array(Int, n, n) as the first line of magic(n)and then return that array? (Or: Does Julia allocate local variables that are restricted to a function's scope on the stack?) As far as comparing to versions of magic that do allocate their output, > simply > define > > magic(n::Integer) = magic!(Array(Int, n, n)) > > This way you can have your cake and eat it too. Measuring and interpreting > the > performance of magic! is far easier than for magic, which is why you > should > probably do all profiling, etc on it. > Sure; my point was that *even* if I use *one* large array instead of 997 different ones, there's still one second time difference, i.e. I've probably missed some possible optimizations. - Phillip
