Tue, 16 Feb 2010 21:56:46 +0100, grauzone wrote: > retard wrote: >> Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote: >> >>> retard wrote: >>>>> Granted, even if logging is disabled, the compiler will push the >>>>> arguments on the stack and call logInfo(). >>>> This is a case where a JIT compiler wins. The code runs equally fast >>>> without the call at all and with logging turned off (dynamically). In >>>> languages like D, the like has to be statically turned off unless >>>> compilers have any new dynamic optimizations. >>> Can the JIT really do this optimization? It sounds as if it'd detect >>> that the variable never changes, and generate code with that fixed >>> value. >> >> It sure can recompile the code assuming that the logging policy doesn't >> change that often - in case it does change often switching the code >> might have larger overhead than testing the condition. In real life you >> would probably start the program with either logging on or off. With >> JIT compiled languages, the decision can be postponed to runtime, in D >> it > > We're talking about a globally accessible runtime variable here, right? > Not just a local variable that was detected to be constant. What I don't > understand is: how does the VM efficiently detect, that the value never > changes, and that generating code for that fixed value may be > worthwhile? > > It is well possible in theory: the VM could just set up write barriers > to detect changes to a variable, and then recompile speed critical code > that uses the variable. > > But it had to collect statistics about all accessed variables, and then > decide to recompile the code. Both collecting and analyzing statistics > and recompiling code takes time, and it has to be fast enough to not > slow down the program even if there are "misses" (e.g. unexpected > variable writes). > > Other typical JIT optimizations sound easy compared to this case. I'd be > really interested how this works out.
I need to study this further. A quick test just showed that the logging code didn't affect performance in any notable way when I logged things in a tight inner loop.
