Garbage collection (crashing on Windows)

Mark Waddingham mark at livecode.com
Sat Aug 20 05:48:46 EDT 2016


Ah! Using repeat for each key is essentially using the keys of an array as a 'proper list' - it is probably the fastest way currently to iterate over a sequence of strings.

In this case the value of each element in that array is immaterial - so the performance benefit comes iterating over the keys in this manner, rather than the way that array was constructed.

Mark.

Sent from my iPhone

> On 20 Aug 2016, at 00:07, Mark Talluto <mark at canelasoftware.com> wrote:
> 
> I do not remember how much of a performance boost we got from manipulating long lists this way, but if memory serves, it was quite beneficial.
> This code sample is just something I made up on the fly. Hopefully it demonstrates the value of this method.
> 
> command createArray
>     local tListOfRecordIDs, tTableID
> 
>     put fld "recordID data" into tListOfRecordIDs
>     put uuid() into tTableID
> 
>     --FOUND IT FASTER TO WALK THROUGH LONG LISTS
>     --WHEN WE PUT THEM IN AN ARRAY LIKE THIS
>     --ONCE THE ARRAY IS MADE, IT WILL BE USED MANY TIMES OVER
>     --NEGATING THE COST OF MAKING THIS ARRAY
>     repeat for each line xRecordID in tListOfRecordIDs
>          put empty into tArrayA[tTableID][xRecordID]
>     end repeat
> 
>     processArray tArrayA
> end createArray
> 
> 
> command processArray @rArrayA
>     put the keys of rArrayA into tTableID
> 
>     --WALK THROUGH ARRAY LIST
>     repeat for each key xRecordID in rArrayA[tTableID]
>          --do something with xRecordID here
>          --we might modify something in this list
>     end repeat
> 
>     --WALK THROUGH ARRAY LIST
>     repeat for each key xRecordID in rArrayA[tTableID]
>          --do something with this modified list from previous repeat
>     end repeat
> end processArray
> 
> 
> -Mark
> 
> 
> 
>> On Aug 19, 2016, at 12:22 PM, Mark Waddingham <mark at livecode.com> wrote:
>> 
>> With the current implementation of the engine, the only reason using empty is faster than using pValue is because the latter requires a variable lookup, the former is a constant.
>> 
>> What are you using sValueCache for?
>> 
>> Sent from my iPhone
>> 
>>> On 19 Aug 2016, at 19:37, Mark Talluto <mark at canelasoftware.com> wrote:
>>> 
>>> 
>>>> On Aug 19, 2016, at 10:42 AM, Mark Waddingham <mark at livecode.com> wrote:
>>>> 
>>>> command shareAndStoreKey @xArray, pKey, pValue
>>>>  set the caseSensitive to true -- this is assuming your values are sensitive to case
>>>>  if pValue is not among the keys of sValueCache then
>>>>      put pValue into sValueCache[pValue]
>>>>  end if
>>>>  put sValueCache[pValue] into xArray[pKey]
>>>> end command
>>> 
>>> 
>>> Hi Mark,
>>> 
>>> We have been doing:
>>> put empty into sValueCache[pValue]    --as an optimization. 
>>> 
>>> How does this compare to:
>>> put pValue into sValueCache[pValue]    --in terms of performance?
>>> 
>>> 
>>> Best regards,
>>> 
>>> Mark Talluto
>>> livecloud.io
>>> canelasoftware.com
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




More information about the use-livecode mailing list