LiveCode Forums

Yes to script-only stacks as the way to go for sharing classes.
And you can promote them to substacks when creating a standalone app.

Understatement follows

Agreed, there was a lot of useful stuff in Richard's stack.

...but do note that you'd benefit from looking at the code for either 4W Flight Recorder and/or the built-in message watcher stack because the functions and mechanism for handling this aren't documented.

Ha! I get it now. So there is indeed cross-platform parity for "the long milliseconds". Thanks.

Ah. Did you not expect a fractional part? That's the whole point of the "long" variation.

mrcoollion- your stack isn't really showing anything useful because of the time it takes LC to execute another statement, and more importantly, to update a field on the screen. Locking the screen would help, as would putting the results into variables before the subtraction and *then* updating the s...

I'm not sure that has changed has it? :D That in itself certainly hasn't changed, but a more granular approach to timing can result in orders of magnitude benefits. As usual, you make several good points here. But I think benchmarking and profiling are related but different actions with different o...

I avoid "do" whenever possible for the slowness reason.
I use dispatch frequently, just have to remember that it returns a three-state value: handled, unhandled, and passed.
So I've gotten into the habit of checking "if it is not unhandled" rather than "if it is handled" after a dispatch call.

Um. On Windows I think the code needs to use a different call to get more resolution. That's part of what I implemented. You need to call both QueryPerformanceFrequency and QueryPerformanceCounter to get the microseconds. virtual real64_t GetCurrentMicroseconds() { LARGE_INTEGER CurrentTime, Frequen...

Dick- do you actually have code that returns the nanoseconds? Er... long milliseconds?
The best I could come up with cross-platform is microsecond timing.

Oh... wait... the "long milliseconds" is built in?
Learned something new today.
Would be nice if that were documented.

Yep... "dispatch" turns out to be about 5 times faster than an equivalent "value".

Haven't looked at this, but my guess is that "value" does the same sort of runtime parsing as "do", so yes, I'd expect it to be slower.
Hmmm... should be an easy benchmark... <goes back to the laboratory>

Apparently. The current code gets the microseconds, then divides by 1000 to return the milliseconds.
Benchmarking, of course, will depend on the overhead of the enclosing code, and that may be what Mark was referring to.

Twenty years down the road now, "the milliseconds" is no longer granular enough for accurate timing of events. Profiling code, for instance, has to rely on averaging multiple runs in order to get anything resembling real command timing. I've implemented "the microseconds" locally. Is there any inter...

I couldn't work around that bug so I made it as one big widget

That's depressing.
I've been playing around with the underlying C code a bit, and I've gotten it to work sometimes, just not consistently. Or reliably.