On 05/20/2017 04:53 AM, Colin McCormack wrote:
>> Hi Mathieu,>> I don't believe you. Anything which adds functionality to an > optimally implemented proc must add overhead to it. You might argue > that proc as implemented is sub-optimal, in which case thank you for > finding a way to optimise it. You might argue that you cannot measure > any difference between the optimal and the extended versions, in which > case you need to measure more closely. You might argue that the > difference is insignificant, or that it's worth the cost, which begs > the question of why using proc to provide the extension is significant > or not worth the cost.>> If you're honestly arguing that you have two (otherwise identical) > pieces of code, one of which implements a discriminator and one of > which doesn't and the one which performs more computation does so with > no additional computation time, then either I have a fundamentally > flawed view of what computation is, or you do.>
In an ideal implementation of this, the overhead, for procs that do not
use the new functionality, will be all in proc definition, not proc
execution.
Since proc definition is a vanishingly rare event compared with churning
away in inner loops, I expect that for typical scripts the overhead will
not be measurable.
It would appear that Mathieu thought that you were speaking of
execution-time overhead.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core