Howdy, Joel:
> I did some test a while back that indicated that > > set [word1 word2 word3 ... wordN] reduce [ > expression1 expression2 expression3 ... > ] > > takes a surprising performance hit compared with > > word1: expression1 > word2: expression2 > ... wordN: expressionN > . . . > Is it reasonable to believe that the majority of the extra > time required by the block SET is due to REDUCE -- > specifically the time required to allocate, and store > values in, a new block? Well, REDUCE will add some overhead because it adds another thing to evaluate and, as you indicate, does create a temporary block to return as a result, but there's some other overhead as well. Consider what happens when REBOL encounters the following: A) SET [foo bar] [1 2] B) foo: 1 bar: 2 First: A) we see SET, we evaluate the word SET and determine it's a NATIVE. We figure out how many args it takes, then collect the arguments (evaluating those in the process) and then we call the native. B) we see FOO:, it's a set-word, to evaluate the set-word we simply evaluate the next argument and we're done. Back in case A) We see that it's a block of something to SET so we're trucking down the block. We need to make sure that each thing is a word before we try and set it. Bad things happen when you try to set, for example, a number to some value. This used to crash REBOL: set [1 2 3] [4 5 6] So this additional but necessary error checking adds some overhead. Again, in case B) after encountering BAR: we just evaluate the next argument and we're done. We've only evaluated two arguments in this case. The process of evaluating a SET-WORDS sets it, so it will always be more efficient than using a NATIVE, and the native has to worry about being passed bogus stuff. The difference in speed is a matter of a difference in the complexity of the expressions and a difference in the amount of evaluation that occurs. The question of efficiency and readability reminds me: INSERT TAIL will always be quicker than APPEND, but most people justifiably use APPEND. I tend to use REBOL idioms to get me down the road. If and when I ever determine that I need a speed up then I can go back and optimize. If I always picked my code based on efficiency I wouldn't use mezzanines functions, just natives. > Any thoughts on how to get the benefits of inner functions > (nice "packaging" and communication of ideas, maximum > locality, minimizing global namespace impact, shared > context) without the overhead of redefinition on every use? REBOL modules. (-; Or contexts in the meantime. -jeff -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
