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