Opportunity to optimize chunk expressions?

[FourthWorld]

Check out lines 2172 and 2185 here:
https://github.com/runrev/livecode/blob ... /chunk.cpp

In xTalk we normally try to make function calls outside of a loop, using a local var inside to keep the loop itself as tight as possible.

Would it make much difference there if the getlinedel() and getitemndel() calls were outside the loop?

[LCMark]

@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.

[Simon]

Sweet!
Now I know what mwieder meant:
http://forums.runrev.com/viewtopic.php? ... 63#p104663
Good to see that posts aren't all candy floss.

Simon

[FourthWorld]

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'.

A wise and language-independent maxim, hence my bringing the question here before wasting time dusting off my C compiler to experiment with this in git.

Thanks for the background. From what little reading I've done about Clang I had a hunch it might be smart enough to handle this automatically, but I so crave performance I figured it wouldn't hurt to ask. Very helpful reply - I appreciate your taking the time.