How can we dynamically create variable names from changing value "x" on a loop?

[Mark Waddingham]

Apologies - I clicked the wrong button in my email client and managed to 
send a partially composed message. Here is the correct version!

On 2016-11-08 12:48, Ben Rubinstein wrote:
> The point is that in my first pattern, I have outside the loop
> assigned column (item) indices to named variables (based on the items
> of the first, header, row). In the loop LC then has to locate the
> indexed items in an individual data row.

In the first pattern:

repeat for each line tRec in tTSVdata
   doSomething item viUserID of tRec, item viUserName of tRec
   ...
end repeat

The 'item <constant> of tRec' expressions cause the engine to iterate 
through tRect until it has found the relevant item. This means that this 
single line will be looking through the tRec string twice from the start 
- the first time up until the viUserID'd item, the second time up to the 
viUserName'd item. The speed of this will largely depend on how large 
the item indicies are, and how large tRec is (and where the items fall 
in tRec).

If the item indices are small, close and near to the start, and tRec is 
small, and you don't use 'item ... of tRec' anywhere else in the loop, 
then it will likely be faster than anything else.

> In the second pattern, the code which happens to be in a function for
> neatness has to create a new empty array, and chunk both the data row
> and the header row in order to get column names and values to put into
> the array. You can loop over one set of items, but not both, so LC
> still has to locate indexed items in at least one case.

put line 1 of tTSVdata into tColumnNames
delete line 1 of tTSVdata
repeat for each line tRec in tTSVdata
   put explodeRow(tRec, tColumnNames) into aData
   doSomething aData["User ID"], aData["User Name"]
   ...
end repeat

The performance will largely depend on the implementation of explodeRow 
and (as you said subsequently) how many columns you want from the row.

If you only want 2 then unless each tRec is very long and you are 
fetching two items near the end then the non-array version will likely 
be faster. If, however, the two items are near the end of the row or you 
are wanting to access lots of items then this will be faster than 
either:

repeat for each line tRec in tTSVdata
   split tRec by tab
   doSomething tRec[viUserID], tRec[viUserName]
   ...
end repeat

The difference here is that with the 'item' approach the speed will 
reduce quadratically with the length of tRec and the max(viUserId, 
viUserName); with the 'split' approach the speed will reduce linearly 
with the length of tRec.

Depending on the average lengths of tRec and values of viUserId / 
viUserName, at somepoint the 'item' approach will start to be 
significantly slower than the 'split' version.

The explodeRow approach sounds like it has lots of overhead. A fair 
amount of the overhead could probably be eliminated by doing 'split 
tColumnNames by tab', and then using array access in explodeRow to form 
the aData array (also making sure explodeRow is private will help too).

Just my two pence.

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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