I wasn't sure what people were talking about with lock screen performance issues, so I did a simple test: I set up a button to either lock the screen once, or twice, and then timed setting the loc of the button while the screen was locked. I didn't time locking the screen; just the movement while locked. As I hoped, I didn't find any difference between locking once or twice, either in 6.7.3, or in 9.0.1 (on an up-to-date Mac).
But... There was a significant performance difference between 6.7.3 and 9.0.1. *Maybe* this is Unicode related? In any case, this script takes about 0.04 seconds in 6.7.3, and 0.24 seconds in 9.0.1: on mouseUp put the loc of me into L1 put L1 into L2 lock screen put the long seconds into T repeat 100000 set the loc of me to L2 set the loc of me to L1 end repeat put the long seconds - T into T unlock screen put T end mouseUp Then I noticed that I had forgotten one line of code. I changed it to this: on mouseUp put the loc of me into L1 put L1 into L2 add 100 to item 1 of L2 lock screen put the long seconds into T repeat 100000 set the loc of me to L2 set the loc of me to L1 end repeat put the long seconds - T into T unlock screen put T end mouseUp ...and found that in 6.7.3 that change increased the duration to about 1.25 seconds -- a performance hit of about 30x just because a locked-screen button is actually moving. In 9.0.1, the time changed to about 0.35 seconds. So if the button *isn't* moving, 6.7.3 is much faster, but in the more practical and likely case that the button *is* moving, 9.0.1 is faster. So ¯\_(ツ)_/¯ On Thu, Jan 3, 2019 at 11:03 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Read through this whole thread, optimistic that I'd find the list of > things that differentiate v6 and v9 so we can hone in on actual solutions. > > I learned two things: > > - lock/unlock changed > > - It's apparently easier to write a thousands of words philosophizing > about how a small team of C++ programmers should provide a uniform > scripting interface for a nearly unprecedented number of OSes, > stay on top of ongoing API changes in every one of those OSes, > multiply features, fix bugs, incorporate Unicode, maintain or improve > all aspects of performance, and keep the joint running than it is to > even briefly summarize concerns about any of the above. > > Is there an actual list of concrete concerns here that the team may be > able to take action on or at least explain how/why the change exists, or > did I just spend an hour reading that I'll never get back? > > I feel rickrolled. > > > I've worked with too many people moving from Drupal 7 to Drupal 8, or > Python 2 to 3, or any version of Apple's C headers in the '90s that > broke declarations quarterly, or HyperCard 2 to 3, to get too > out-of-breath about undoing workarounds in old code to work > with-the-grain for v9's enhancements and fixes for long-standing > anomalies. When I describe LC's high priority for backward > compatibility to nearly any other experienced dev I know, they look at > me like I'm high and spouting tales of dancing ponies; many professional > development systems consider backward compatibility a very minor > nice-to-have, if they devote time to it at all. Many of us here buy > computers from a hardware vendor with a similar view. > > As for performance, in threads with Geoff Canyon, Mark Talutto, and > others who provided real-world use cases and metrics, we do see some > performance degradation in v9 from v6 in some cases, a surprising amount > on par given how relatively little work v6 had to do under the hood with > encodings and types, a few things a wee bit faster, and overall such a > strong comeback from the v7 series that it should be clear to those > earnestly following along that the team has indeed been quite evidently > working on performance, and delivering improvements over the v9 cycle. > > Then again, my work may not touch the items on the concern list. I > can't know, because I couldn't find such a list in this long thread. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode