Existing syntax that bugs you

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

[jacque]

On the other hand, the "is in" does the same thing and works as you'd suspect:

put "foo" is not in "bar"

[edgore]

This is true - I think it's actually why contains bothers me. And, like I said, it's a quibble.

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

[FourthWorld]

"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?

[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

[FourthWorld]

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

[dunbarx]

Richard.

That sounds like a challenge.

Craig

[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

[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

[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

[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

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

[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

[mwieder]

Dang. I had a perfectly good theory until you tested it. <g>