Author stargaming
Recipients belopolsky, pitrou, stargaming
Date 2008-02-29.19:53:13
SpamBayes Score 0.000419067
Marked as misclassified No
Message-id <>
Later on, when Greg mentions the current for/if performance asymmetry,
Guido states: 

> Fair enough. So maybe *you* can contribute a patch?

I don't read this as a rejection, but of course you're right -- this
patch is purely an optimization. As already written in my initial
comment (and discussed on the mailing list), there would be no change in
behaviour: The change from generic iterator behaviour to specific range
performance is transparent to the end-user.

I don't see how the other patches interfere with this one. Waiting until
the development of the range object itself has a stabilized and we
decided upon a member type/API seems sensible. Still, this patch would 
be valid on its own.

Now, your impulse is right: having the performance enhancement in the
bug tracker doesn't help much -- we need a resolution for this. If
someone could review the patch, tell me about the critical parts or
point me to references on how to improve it, I'd be really glad!

On the mentioned unit tests: I'm unsure how to verify this behaviour
since I expect it to affect runtime *only*.

PS. With the new tracker, wouldn't the "resource usage" type fit best?
Date User Action Args
2008-02-29 19:53:16stargamingsetspambayes_score: 0.000419067 -> 0.000419067
recipients: + stargaming, belopolsky, pitrou
2008-02-29 19:53:16stargamingsetspambayes_score: 0.000419067 -> 0.000419067
messageid: <>
2008-02-29 19:53:15stargaminglinkissue1766304 messages
2008-02-29 19:53:13stargamingcreate