I think this is because the loop might have zero iterations, and in that case `i` might not be initialized. Variables that might be used uninitialized get pessimized. We could improve this by representing such variables internally as a pair of a fast variable and a boolean flag. On May 21, 2014 3:41 PM, <[email protected]> wrote:
> Good catch. I have no idea the reason behind this behaviour. It would be > interesting to know why. > > On Wednesday, May 21, 2014 7:58:02 PM UTC+2, Peter Simon wrote: >> >> I don't think this slowness is because of type instability, as I >> understand the concept. On a 64-bit machine `Int === Int64` is true. >> Also, the following is also slow and results in lots of allocation: >> >> local i::Int64 >> >> as does simply declaring >> >> local i >> >> However, if one completely leaves off the declaration/initialization of i >> (and returns nothing), the code is again fast. Also >> >> local i::Int64 = 0 >> >> results in fast code. Apparently, if the loop variable is to be retained >> after the loop terminates, then for best performance it must be initialized >> and not just declared `local` prior to the loop I'm not sure why this is >> so. >> >> --Peter >> >
