Parent of Target

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps