On 2017-08-10 09:32, Ali Lloyd via use-livecode wrote:
Jacque recently showed me the speed difference between explicitly
writing out the element of an object reference:
get the width of btn 1 of cd 2 of stack "MyStack"
...vs other forms like long IDs:
put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
get teh width of tObj
The latter is much slower, yet long IDs are so good to work with.
The only reason this is true is that in the second case you are
resolving
the object twice. It is not true in general - the second time the long
id
is used it will use the id cache which is constant time, whereas
"button n"
is O(n). Try benchmarking repeated use of the stored long id vs the
number
version, especially if the numbers are large.
So it's horses for courses. If it's a one-shot object access then the
number form is faster. For repeated use, get the long id.
Just to expand on what Ali said...
There is an overhead in parsing a long id string - however, that is
proportional to the length of the id string which are generally quite
short. Also, this is purely 'parsing' it is basically munching chars and
branching which means the 'step' taken at each char is very very very
fast. Certainly something which is overwhelmed by whatever operation you
might be doing with the resolved chunk.
What takes up the time in resolving object references is finding the
objects at each step.
If you use the indexed form - e.g. btn 3 - then the time taken is
proportional to the magnitude of the index as the engine has to step
through a list to find the object.
If you use the id form, however, then the lookups are cached at the
stack level after the first time they are resolved. The id of an object
is unique within the confines of a stack, and every stack has a
hash-table which caches id->objectptrs internally.
If you are doing custom control type work (which is where you tend to
have to manage lots of child control references), then I'd generally
suggest not using long ids, but instead just store the id property of
the child object and use explicit syntax:
control id ... of me -- here I'm assuming that 'me' is a group ;)
The reason is that this is (after the first lookup for any given id/me
pair) a completely constant time lookup:
- 'me' is stored internally as a direct pointer
- id's can be looked up in the stack hash table.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
