LiveCode Forums.

Thierry wrote: Mon Mar 01, 2021 12:06 pm Mmm, actually I warned you about this...

function sortArray @pArray, pDirection, pSortType, pKey
   local tNextIndex, tSortedArray, tSortText
   if (pDirection is not in "ascending,descending" and pDirection is not empty) or \
         ( pSortType is not in "international,numeric,datetime,text,binary" and pSortType is not empty) then
      answer "Malformed parameters - sortDirection must be either Ascending, Descending or empty" & return & \
            "sortType must be either 'international', 'numeric', 'datetime', 'text', 'binary' or empty"
      return pArray
   end if
   get the keys of pArray
   if pKey is empty then 
      put merge("sort lines of IT [[pDirection]] [[pSortType]] by pArray[each]") into tSortText //1-dimensional array
   else
      put merge("sort lines of IT [[pDirection]] [[pSortType]] by pArray[each][pKey]") into tSortText //multidimensional array
   end if
   do tSortText
   repeat for each line tKey in IT
      add 1 to tNextIndex
      put pArray[tKey] into tSortedArray[tNextIndex]
   end repeat
   return tSortedArray
end sortArray

stam wrote: Mon Mar 01, 2021 12:42 pm Yep, you did indeed. As always i'm ever so grateful for all your advice and contributions which i've found absolutely invaluable during my short time on this forum (especially with regex!) - didn't mean anything by my comment, just that that was needed for multidimensional array sorting.

On some cursory testing, i now see why you left it out - you can't use this for 1-dimensional arrays as Merge() doesn't evaluate anything in brackets it seems...

Based on this i've revised the code to cater for both 1- and multi-dimensional arrays. Includes a conditional (without pKey as per your code, but also with pKey when needed)... can't get away from at least 1 if statement i guess...

Code: Select all

function sortArray @pArray, pDirection, pSortType, pKey
   ....
   if pKey is empty then 
      put merge("sort lines of IT [[pDirection]] [[pSortType]] by pArray[each]") into tSortText //1-dimensional array
   else
      put merge("sort lines of IT [[pDirection]] [[pSortType]] by pArray[each][pKey]") into tSortText //multidimensional array
   end if
   .....

function sortArray @pArray, pDirection, pSortType, pKey
   ....
   local sortCmd = "sort lines of IT [[pDirection]] [[pSortType]] by pArray[each]"
   
   if pKey is not  empty then put "[pkey]" after sortCmd
   
   put merge( sortCmd) into tSortText

   .....

stam wrote: Mon Mar 01, 2021 6:01 pm Good to know about lock screen
i've used it but haven't seen a massive increase in speed but maybe i've not been doing stuff that was taxing enough to make it obvious (and haven't bothered time-logging)

I guess it will (almost?) never hurt to use lock screen though

plus I think using or not the @ prefix in your parameter won't change much too...

Thanks to Bernd the estimated 56 hours for processing a datafile is down to a real 70 seconds. The main speed problem was caused by passing a copy of the complete data variable to a function that was being called over a million times. Livecode just choked. The solution was to add the @ character before the parameter name in the function declaration, this makes livecode pass a reference to the data rather than the default of sending a copy. the data is stored in theBinarydata e.g.

bobcole wrote: Tue Mar 02, 2021 4:31 am ...there was an issue with using the "do" command....
...somehow related to Apple not liking programs that have potentially self-altering code in their App Store....

Simon Knight wrote: Tue Mar 02, 2021 8:45 am Here is a link to my post from 2011

viewtopic.php?f=32&t=7069&p=32207&hilit ... nce#p32207

In it I estimate that an operation would take 56 hours, this was reduced to 70 seconds mostly by switching to referenced variable passing. Mind you the variable was quite large at 70Mbytes.

FourthWorld wrote: Sat Feb 06, 2021 7:35 pm In fact, it's so useful to pass by reference that the engine now does that automatically by default (as of v8 or so).

It uses "copy on write" by default, so even if you don't explicitly declare a param as reference ("@"), it won't actually make a copy into you perform some action which would alter it. If you want that alteration to be reflected in the calling handler, use @ before the arg name in the definition handler.

In your case, the only operation is read, so you should see no difference in performance whether you use @ or not, since only a pointer to the original data is what's being used by default.