Comparative speed in switching among groups
ambassador at fourthworld.com
ambassador at fourthworld.com
Sun Nov 26 19:02:30 EST 2023
An excuse to benchmark? Sure, I'll bite. :)
I didn't test the third option because I feel confident we'd find it similar to the second but with the extra overhead of object/memory allocation.
My hunch was that groups would be faster than cards, because everthing needs to be unpacked and ready to go on a card but when going card-to-card there's presumably some setup and teardown.
But boy oh boy was I surprised by the difference.
A bit about the test stack:
I wanted a worst-case scenario, looking for things we know take a lot of rendering time. So I made a group with a field containing > 20k chars so there's a lot of line wrap calcs, a fairly sizable image shrunk small with resizing set to "best", and two buttons so the engine needs to coordinate with the OS.
Then I replicated that group so there are three copies, grouped that and set a blue background, then made a copy of that bigger group and set it with a red background so we can tell them apart.
Then I copied the blue group to a second card, the red to a third, and wrote a script that does the timing of each.
The test stack I used is here (I added "SLIM" to the name because the first version I attempted had more than twice as many subgroups and took too long to work with, lots of beach balls on card-to-card and even saving):
https://fourthworld.net/lc/TransitionTimingTest%20SLIM.livecode
Bottom line, in millisecs for just 5 iterations on an M1 Mac:
Groups: 141
Cards: 13619
And even that was after adding a couple details to the group hide/show so I could tell they've changed, with a lock/unlock and a wait 0 you probably wouldn't need in production.
I suspect most layouts won't encounter this much of a difference. After all, I did choose the elements I could put together quickly with rendering impairment in mind.
But I suspect the difference would still show itself in lighter layouts.
And now I'm curious: what are you working on where layout transition speed is critical?
--
Richard Gaskin
FourthWorld.com
David Epstein wrote:
> Does anyone have practical experience or an understanding of the engine that would
> cast light on the relative speed of some alternative ways of doing things? I want
> to switch among a number of different groups, each of which may contain its own
> fields, graphics, buttons, and images. Possible approaches:
>
> - Have many different cards, each with a group peculiar to it, and GO TO each card
> as desired, or
>
> - Have one card, with many different groups, and SHOW/HIDE the groups as desired, or
>
> - Have many different cards, each with a group peculiar to it, and COPY a group from
> an unseen card to a single card that is always seen (and DELETE the unwanted group
> on that single card).
>
> There are other considerations that affect a choice among these methods, but my concern
> here is the speed with which I can switch from displaying one group to displaying
> another. I am wondering whether at some level these methods all amount to the same
> thing from the engine’s point of view (since everything is in RAM in any case).
More information about the use-livecode
mailing list