Slow Fields and Handler Haunts

[FourthWorld]

Actualy, Dixie's benchmark appears to account for the field display time, since the final measurement is taken after the instruction to put the value into the field.

FWIW I generally find slightly faster overall performance under Windows than OS X with LiveCode (slowest of the bunch is the Linux engine, but I'm hopeful that'll be brought up to par in the future).

Your scrip is simple enough that I have to admit I'm mystified as to why it's noticeably slower on your system. Might there be anything unusual on your system which could affect display times?

[Luisa Klose]

FourthWorld, if it were my system, wouldn't I see this happen in the simple calculator and perhaps in other applications?

It seems to me that Dixie's timer stops as soon as the command is sent, not after it is carried out. I may be wrong. Been wrong before

[Klaus]

Luisa,

please try it, just to please us


Best

Klaus

[FourthWorld]

FourthWorld, if it were my system, wouldn't I see this happen in the simple calculator and perhaps in other applications?

That would seem a reasonable conclusion for most apps, but as a multi-platform tool LiveCode relies on its own internal text engine which touches relatively little in the APIs for the text engines of the host OSes. For the most part the LC text engine performs very well (buffering and scrolling large blocks of text in LC fields is noticeably more efficient than in Word, for example), but since you're seeing a difference in performance we have to examine the range of possible causes to try to pin it down.

It seems to me that Dixie's timer stops as soon as the command is sent, not after it is carried out.

It's true that the final measurement takes place before the handler ends, but LC is in most cases a single-threaded process so the putting of the data into the field should complete before getting the closing measurement:

Code: Select all

on mouseUp
   put the millisecs into tstart
   --put the label of the target after fld "display"
   put the label of the target into fld "display"
   put the millisecs - tstart
end mouseUp

If the tedium of benchmarking is of interest (admittedly it's a bit of a fetish for me), this may be worthwhile:

Benchmarking Performance in LiveCode
http://livecodejournal.com/tutorials/be ... vtalk.html

[FourthWorld]

FWIW, I just downloaded your calculator and added a line at the top of the HandleNumber handler to get the milliseconds, and another at the end of that handler to display the difference between that value and the current millisecs in the Message Box.

On OS X I get between 2 and 4ms, and on Windows I get between 0 and 2ms.

Those times are somewhat slow compared to what I normally see in such operations, but I have a lot happening in the background on this machine today so that probably explains it.

The downside to my test is that I haven't been able to turn up a way to replicate the slowdown. It'll be interesting to learn what's causing it if we can.

[Luisa Klose]

Already tried the handler, Klaus. It ends before the problem manifests itself.

I'm here for two reasons: I like the software enough to invest my time and money into it, and I see that it may have a -small- problem that could affect at least one of my projects.

[bn]

Hi Luisa,

could you try to add to your number buttons:

Code: Select all

on mouseDoubleUp
   mouseUp
end mouseDoubleUp

and tell us if it makes any difference?

The small lag I notice if I click very fast on the button on my MacBook Pro dissapears with above handler.

Kind regards

Bernd

[Luisa Klose]

Bernd, you did it! Thank you!

Looks like some of the clicks were being interpreted as double clicks.

Sorry to be such a pain in the butt, folks. Thank you for your help & patience.

[Klaus]

Glad you got it working now and that it was not a serious problem!