To template or to lock?

Sarah Reichelt sarah.reichelt at gmail.com
Sat Feb 6 06:35:05 EST 2010


On Sat, Feb 6, 2010 at 9:11 PM, David Bovill <david at architex.tv> wrote:
> Pretty sure that setting a templateXXX to a bunch of properties is the way
> to go if you need to repeatedly create the same type of object, but I was
> wandering about one-off's? I'm looking at a community provided script - and
> it used the templategraphic technique to create each object - like this:
>
>   1. set the prop x of the templategraphic to n
>   2. set the prop y of the templategraphic to m ....
>   3. create the graphic
>   4. reset templategraphic
>
> In my not entirely scientific speed tests I get 168 ticks for the creation
> of 100 objects using this technique. As fo the technique of simple creation
> and locking the screenr:
>
>   1. lock the screen
>   2. create the graphic
>   3. set prop x, y, z....
>   4. unlock the screen
>
> I get 94 ticks for the creation of 100 objects using the lock screen
> technique for each object creation. I guess simple creation of the object is
> not only a little safer (no forgetting to rest), but nearly twice as fast
> (which is surprising).


I would combine the 2 techniques.

Before the repeat loop, set the templateGraphic's properties to those
that are the same in each graphic.
In the repeat loop, create the new graphic and set the properties that
are different for each graphic.
After the repeat loop has finished, reset the templateGraphic, but
only do this once.

This is untested, but would seem logically to be the most efficient method.

Unless you really need to see the graphics as they are created, it
will be much faster if you put a lock screen before the repeat loop
starts, rather than locking & unlocking for each object.

An alternative that I have used is to have a hidden object that is
already set up the way I want, then just clone it instead of creating
a new object from scratch. But I haven't done any benchmarks on that,
since I usually only need it during development.

Cheers,
Sarah



More information about the use-livecode mailing list