On 07/11/2014 09:53 AM, simendsjo wrote: > On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote: >> On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: >> […] >>> A little anecdote.. I once got a 20% speed increase in Python by >>> "moving" a variable instantiation outside a tight loop. >>> i = 0 >>> # loop here >>> i = something >>> >>> rather than >>> # loop here >>> i = something >> >> This is interesting. I can believe there is some performance benefit, >> but I am not sure I believe 20% improvement. If you can send me the code >> you were using, I would like to do some benchmarking on this. > > Yes, I was very perplexed when I was profiling and finally found the > main offender. Unfortunately I don't have the code - it was a project > done for a past employer back in 2006/2007 (Python 2.4 IIRC). > >>> The compiler wasn't smart enough to do this. >> >> The Python compiler cannot and will never be able to do any such thing. >> Indeed if it did any such thing, it would be an error since it >> significantly changes the semantics of the program. Thus not doing this >> is not the fault of the compiler. The fact that you were able to do >> this and it appeared to give you the same results just means that the >> change in program semantics did not affect your computation. Which is >> good, but not something the compiler could determine. > > I think of this as a fault in the compiler. It was quite obvious (to me) > that nothing else relied on the value so the value didn't have to be > created on each iteration.
Can that 'i = something' expression be monkey-patched in Python? If so, it could have side-effects to make the program change semantics like Russel Winder means.
Ali
