LiveCode Forums.

Posted: **Wed Jun 19, 2013 11:45 pm**

OK... so an email from Kevin got me thinking about lcVCS again and I think I've come up with another feature idea to help it along. Because lcVCS translates object references to UUIDs and back there is a certain point in the import where if it doesn't know the UUID to object ref mapping that it needs to search all objects in all stacks in memory... obviously this is a step that can make things lock up for a bit... what I was thinking is a command something like _internal resolve image but for finding custom property values:

Code: Select all

_internal resolve setName["propertyName"] with value theValue [and limit N] [relative to objectRef]

Of course if this doesn't need to be used by anybody else then it could just be:

Code: Select all

_internal resolve uuid theValue

Implying a limit of 1 and no relative objectRef...

Posted: **Thu Jun 20, 2013 11:47 am**

In the first instance, the fastest/quickest/easiest thing to do here at the moment would be to generate the index as a LiveCode array:

Code: Select all

_internal build uuid index [ for stacks <stack list> ]

The array returned would just map UUID to rugged id. The only potential issue here is scalability due to the size of the array that could be generated (UUIDs take 36 bytes as a string, rugged id's take at least that, then there's the overhead of the array structure itself ).

If that does turn out to be a problem, then the uuid index could be internalized:

Code: Select all

_internal create uuid index [ for stacks <stack list> ]
_internal lookup uuid <uuid>
_internal destroy uuid index

The cost here is much less - UUIDs 16 bytes, control pointer 4 bytes, specific hash-table implementation only 4 bytes per entry.

In either case you'd only be paying the cost of scanning all objects once per export, rather than each time you need to lookup a uuid.

Then, in the future, this could be further sped up by having the UUID as a private piece of metadata attached to objects. (And thus not require searching custom property sets).

My general advice would be to start with the LiveCode array approach and then build up based on performance evaluation.

Posted: **Thu Jun 20, 2013 2:15 pm**

Hmm... I already only scan once per export. I basically already have an array of uuid -> long id... performance is not too bad as long as the uuid is in that array which it is if the object being referenced was in that stackfile. It's only when you have the referenced object not in the stackfile that you have an issue. For example, the IDE uses a separate stackfile for icons so when exporting a stack it needs to parse that file... at the moment I've made it generic (look in all stacks in memory) but perhaps I need to have some project metadata so I know what stack files the references would be found in... maybe the metadata could also be used to regenerate a whole project rather than just a single stackfile...

I need to think on this some more... essentially what I'm starting to think is if we aren't going to get proper uuids and lcVCS is still required to map to and from then I can probably design around this parsing all stackfiles in memory bit...

The project metadata may also make it possible to use lcVCS as a command line tool which would be better... either as a process opened by the IDE or to integrate into automated builds and git hooks.

The other thing is perhaps the best course of action is I make the changes I want to do to use the 6.1 stuff then I do some profiling... perhaps there's other bottlenecks that are more important to deal with and maybe lower hanging fruit...

Posted: **Thu Jun 20, 2013 5:33 pm**

to integrate into automated builds and git hooks.

...searching in vain for the upvote button...

LiveCode Forums.

resolve object for custom property value

resolve object for custom property value

Re: resolve object for custom property value

Re: resolve object for custom property value

Re: resolve object for custom property value