@FourthWorld: Absolutely none at all - that code isn't used in 7.0 as it has all been refactored (this is true of any code inside a LEGACY_EXEC #if / #endif block). The code is kept in the original source file (as the new implementations have moved) so that we don't miss any bugfixes / changes made on the older branches (6.6.x / 6.7.x) when we merge them in. So a better question would be - if that code were being used (as it is in previous version) would moving the function calls out of the loop make any difference - and the answer is still absolutely none at all.
In C for functions which have high computational cost then, yes, hoisting them out of significant loops will in theory reduce runtime (but it is important to remember that function call cost in C is exceptionally low - it is nothing like the costs to such operations we currently have in LiveCode). However, C/C++ compilers these days are all 'highly-optimizing' meaning that they aim to reduce if not eliminate all costs to abstraction if they can. In particular, in this case, getitemdel() and getlinedel() are const inline member functions of MCExecPoint which return one of the execpoint's instance variables. The compiler, in this instance, will therefore inline the call - with this phase of the compiler's optimization, the loop effectively becomes:
Code: Select all
do
{
if (*sptr == ep->itemdel && sptr + 1 < eptr)
items++;
}
while (++sptr < eptr);
A further optimization that is likely to be performed is 'invariant code hoisting' - this moves code which is inside loops but does not change outside of it. Abstractly, the compiler will perform the optimization you suggest:
Code: Select all
char t_itemdel;
t_itemdel = ep -> itemdel;
do
{
if (*sptr == t_itemdel && sptr + 1 < eptr)
items++;
}
while (++sptr < eptr);
Of course, what machine code instructions you end up with will very much depend on architecture. A processor which has few registers but instructions which can take rich memory access operands (like i386) might be best having code which does the indirection inside the loop (i.e. the ep -> itemdel) since the processor will do the appropriate thing ; a processor which has many registers and limited memory access primitives (such as ARM) would most likely benefit from having ep -> itemdel in a register before the loop.
There's a famous saying by Knuth which one must always consider when looking at optimizing code - 'premature optimization is the root of all evil'. There's no point in rewriting code in a way which you might think may make it faster unless you have evidence that will show it will actually result in faster code - particularly at the expense of readability.
