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

Reply via email to