Page 1 of 1
Existing syntax that bugs you
Posted: Fri Mar 01, 2013 6:36 pm
by edgore
Since there is going to be a complete rewrite of the core engine over the next X months I thought it might be useful to have a place to talk about things in the current version of the syntax that you find annoying or that might be confusing to people just starting out.
I will start out with "contains". Contains is extremely useful and works perfectly for the positive case:
Code: Select all
if X contains Y then
put "X contains Y"
end if
But the negative case if a bit of a mess:
Code: Select all
if X contains Y is false then
put "X does not contain Y"
end if
It would be much nicer to be able to use:
Code: Select all
if X does not contain Y then
put "X does not contain Y"
end if
A minor quibble, but it does interfere with being able to write english-like code.
Another thing is "in" and "of" in "repeat for each" structures. It would be nice if they were interchangeable since it's a common mistake to switch them, since they both make sense in english.
Do you have any Syntax stuff that nags at you when you are working with Livecode? Post it here.
Re: Existing syntax that bugs you
Posted: Fri Mar 01, 2013 8:28 pm
by jacque
On the other hand, the "is in" does the same thing and works as you'd suspect:
put "foo" is not in "bar"
Re: Existing syntax that bugs you
Posted: Fri Mar 01, 2013 9:58 pm
by edgore
This is true - I think it's actually why contains bothers me. And, like I said, it's a quibble.
Re: Existing syntax that bugs you
Posted: Fri Mar 01, 2013 11:39 pm
by mwieder
"Contains" is actually slower than "is in" because it makes an extra copy of the source string.
I see no reason to continue to use "contains". Or possibly just have the engine cast it to "is in" syntax.
Re: Existing syntax that bugs you
Posted: Sat Mar 02, 2013 12:00 am
by FourthWorld
mwieder wrote:"Contains" is actually slower than "is in" because it makes an extra copy of the source string.
Why would the two not trigger the same underlying implementation?
Re: Existing syntax that bugs you
Posted: Sat Mar 02, 2013 2:18 am
by dunbarx
So much fun.
Code: Select all
on mouseUp
put the ticks into tStart
repeat 10000000
if "aa" is in "aabb" then next repeat
end repeat
answer the ticks - tStart
end mouseUp
on mouseUp
put the ticks into tStart
repeat 10000000
if "aaaa" contains "aa" then next repeat
end repeat
answer the ticks - tStart
end mouseUp
The first is about 3% faster than the second (about 102 ticks vs. 105)
Craig
Re: Existing syntax that bugs you
Posted: Sat Mar 02, 2013 3:14 am
by FourthWorld
dunbarx wrote:The first is about 3% faster than the second (about 102 ticks vs. 105)
When I see benchmarking differences that small I wonder what happens when you switch the order of those two (caching effects and such).
Re: Existing syntax that bugs you
Posted: Sat Mar 02, 2013 3:42 am
by dunbarx
Richard.
That sounds like a challenge.
Craig
Re: Existing syntax that bugs you
Posted: Sat Mar 02, 2013 3:47 am
by dunbarx
After exhaustive effort switching those handlers, and in a new session to boot, I submit that the difference is about the same.
Going to take a well earned rest.
Craig
Re: Existing syntax that bugs you
Posted: Sat Mar 02, 2013 9:41 pm
by dunbarx
Just tried a variation, being intrigued by Mark's comment concerning copies of strings. Anyway, I tried placing the strings into variables, expecting a speed increase over simple literals. I get roughly the same performance ratio, but an overall DECREASE in speed (110 ticks vs. 114 with variables, as opposed to 102 ticks vs 106 with literals)
Code: Select all
on mouseUp
put "aa" into aa
put "aabb" into aabb
put the ticks into tStart
repeat 10000000
if aa is in aabb then next repeat
end repeat
answer the ticks - tStart
end mouseUp
on mouseUp
put "aa" into aa
put "aabb" into aabb
put the ticks into tStart
repeat 10000000
if aabb contains aa then next repeat
end repeat
answer the ticks - tStart
end mouseUp
This seems odd to me, but what do I know? On another note, very little processing here, and the repeat loops about 6,000,000 times per second. Not bad, 2.0 GHz G5.
Craig
Re: Existing syntax that bugs you
Posted: Mon Mar 04, 2013 5:38 pm
by markw
Hi,
Excuse me as a new user butting in on an existing thread. Just saw something worth commenting on - there seems to be a very logical explanation here, entirely consistent with Mark's comment about an extra string copy.
These results suggest it takes 4 ticks to copy a string on your machine. Using "contains" makes 1 extra string copy vs "is in" but this is cached within the scope of the repeat loop. Putting copies into local variables outside of the repeat loop does not prevent them being copied again (i.e. there's very little non-local optimisation going on).
Of course it could be much less straightforward than I'm suggesting - 4 ticks to copy a string vs under 100 ticks for 20000000 comparison operations seems unlikely, unless the result of the comparison itself is cached and the loop is ignored or possibly reduced to a trivial counter. Have you tried significantly different values for the repeat count? It'll be interesting to check the code for those operations when the source is released.
Mark
Re: Existing syntax that bugs you
Posted: Mon Mar 04, 2013 7:19 pm
by mwieder
Popping back in here again...
The cacheing issue came up in another context, and I don't know - it's hard to separate the issues in this kind of a timing loop.
It may also be the case that I'm working with old information: it certainly used to be the case that "contains" was slower because of the extra copy involved, but this may have been optimized in the engine at some point and now, as Richard points out, the two constructs may indeed point to the same code.
At any rate, I usually try to optimize my code for performance as step #3, but from the benchmarks here I don't think the difference is enough of anything to worry about.
#1. Get it working
#2. Get it working better
#3. Get it working faster
Re: Existing syntax that bugs you
Posted: Mon Mar 04, 2013 7:31 pm
by mwieder
Craig-
The literals vs variable thing:
I think this is because the compiler (if you don't have explicitVars enabled) allows you to use strings without quoting them.
I've always thought this was a Bad Idea (yes, I know HC allowed this...), and I think what the compiler has to do is:
Code: Select all
I found a word.
If it starts with a quote then
It's a string literal.
Else
If it's a function I know about then
Process it
Else
If it's a variable name then
Evaluate it.
Else
It's a string variable
End if
End if
End if
So there's extra processing time involved getting to a variable value vs recognizing a quoted string literal.
Re: Existing syntax that bugs you
Posted: Tue Mar 05, 2013 1:46 am
by dunbarx
Mark.
I see what you mean. Unthinkingly (my normal mode of existence), I assumed that a variable in LC was automatically and immediately seen as such, and would be more speedily evaluated. But as you say, without explicitVars, if LC encounters quotes, it knows immediately what to do, whereas with a variable, it may have to think a bit.
Now for some news. I know less than ever. Oh, right, that is not news:
1- I tried this on another machine, a Macbook Air, and the two routines run at the same speed, but slower (198 ticks for both). (1.86GHz Intel Duo)
2- I then tried the following on that Macbook Air:
Code: Select all
on mouseUp
set the explicitVars to "true"
local aa,aabb,tStart
put "aa" into aa
put "aabb" into aabb
put the ticks into tStart
repeat 10000000
if aa is in aabb then next repeat
end repeat
answer the ticks - tStart
end mouseUp
on mouseUp
set the explicitVars to "true"
local xx,xxyy,tStart2
put "xx" into xx
put "xxyy" into xxyy
put the ticks into tStart2
repeat 10000000
if xxyy contains xx then next repeat
end repeat
answer the ticks - tStart2
end mouseUp
The two run at the same speed as the non-explicitVars routines.
I understand, but it does not apply. I am going back to HC. Or to bed.
Craig
Re: Existing syntax that bugs you
Posted: Tue Mar 05, 2013 2:32 am
by mwieder
Dang. I had a perfectly good theory until you tested it. <g>