I think the article is making out trace compilers to be far more limited than they actually are. > Consider these optimization tips: Avoid nested loops. I don

I think the article is making out trace compilers to be far more limited than they actually are. > Consider these optimization tips: Avoid nested loops. I don't think this is true at all. The article is arguing that because a trace only contains one loop, that nested loops can't be trace-compiled. As I understand it, nested loops are totally possible to trace-compile by having multiple traces that link to each other. See what Mike Pall wrote about LuaJIT (http://www.freelists.org/post/luajit/How-does-LuaJITs-trace-compiler-work,1 http://www.freelists.org/post/luajit/How-does-LuaJITs-trace-...): "If the inner loop has a low iteration count, it'll be unrolled and inlined. For most loop nestings there'll be a single trace for the outer loop that goes 'around' the inner loop and joins its exit with its entry. Otherwise traces link to each other in linear pieces." I would take what this article says with a heavy grain of salt. I don't think that tracing JITs are at all like "programming in a straight jacket." Look at the LuaJIT performance optimization guide. There is nothing in there about avoiding nested loops, avoiding tiny loops, or avoiding loops with unpredictable iteration counts. It does however recommend reducing unpredictable branches: http://wiki.luajit.org/Numerical-Computing-Performance-Guide http://wiki.luajit.org/Numerical-Computing-Performance-Guide