> On Dec 30, 2016, at 2:32 PM, J. Landman Gay wrote:
>
> Did someone once say that between "contains" and "is in", one is faster than
> the other?
This is a great question. One of the engineers on the LC team would be needed
to answer this one.
Best regards,
Mark Talluto
livecloud.io
canelas
> Jacqueline L.G. wrote:
> > Did someone once say that between "contains" and "is in", one is faster
> > than the other?
Mark T. wrote:
> This is a great question. One of the engineers on the LC team would be
> needed to answer this one.
There is a real big difference: "is in" are 5 chars and "co
Mark Talluto wrote:
>> On Dec 30, 2016, at 2:32 PM, J. Landman Gay wrote:
>>
>> Did someone once say that between "contains" and "is in",
>> one is faster than the other?
>
> This is a great question. One of the engineers on the LC team would
> be needed to answer this one.
Or you could test it:
[There is always some crazy time overcrossing here, I posted half an hour
before you.]
I have here the following result with your code (in average).
There is a "contains"-repeat and a "is in"-repeat.
If I use one as first and the other as second repeat loop I get that the one
that is called fir
hh wrote:
> There is a "contains"-repeat and a "is in"-repeat.
> If I use one as first and the other as second repeat loop I get that
> the one that is called first is a little bit faster ...
>
> Isn't it that deep in the stomach of LC both use the same
> offset(substring, string) routine?
I wou
On 1/2/17 4:44 PM, Richard Gaskin wrote:
hh wrote:
There is a "contains"-repeat and a "is in"-repeat.
If I use one as first and the other as second repeat loop I get that
the one that is called first is a little bit faster ...
Isn't it that deep in the stomach of LC both use the same
offset(su
On 1/1/17 12:31 PM, pink wrote:
what version of easyJSON are you using? I just copied the library from:
https://github.com/luxlogica/easyjson/blob/master/easyjson.lc
used this code:
put "12345" into tArray["one"][1]
put "12345" into tArray["one"][2]
put "12345" into tArray["one"][3]
But there is interestingly the fact that both are faster than
put offset("foo","this is a string with foo in it") > 0 into r3
(seen by 'enlarging' your test).
Quite clear because "is in" and "contains" do the ">0" test in the engine,
while the above needs a further comparison of two numbers:
pu
The Livecode team imported Apple’s Foundation
Framework so you can use its power inside of a
stack instead of writing extensions. It will be a
little slower than an extension but in many cases
the loss of speed will not be noticeable.
To access all the power of foundation you need to
know objecti
hh wrote:
> I wasn't aware of that, good to know, "is in"/"contains" is 10%
> faster than "offset() > 0".
But as with many benchmarks, it's helpful to keep the absolute times in
mind.
In my quickie test script I had to use 1,000,000 iterations just to get
any appreciable duration to test.
if we import an animated gif into a card called "image-resources" which might
be e.g. card 3. with repeat set to -1… i.e it is running continuously…
When are on Card 1… is that GIF still running and taking up CPU cycles even
though it is effectively "hidden" by virtue of being on Card 3?
OR
is
says the guy who doesn't scrape.
On Mon, Jan 2, 2017 at 6:14 PM, Richard Gaskin
wrote:
> hh wrote:
>
> > I wasn't aware of that, good to know, "is in"/"contains" is 10%
> > faster than "offset() > 0".
>
> But as with many benchmarks, it's helpful to keep the absolute times in
> mind.
>
> In my q
12 matches
Mail list logo
