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). _______________________________________________ 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
