Go to card has become slow

Bob Sneidar bobsneidar at iotecdigital.com
Wed Apr 8 10:04:58 EDT 2020


Interesting results Richard. I hope the mothership is monitoring this thread. I’ll give the test a go later today. I have to go out (believe it or not) to some customers this morning and early afternoon. 

Bob S


> On Apr 7, 2020, at 10:56 PM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Great test set, Neville. Thanks for posting that link.
> 
> The hardware on my Linux and Win boxes is so different I don't have a strong opinion there. But I did modify your main test script to see what I might learn from isolating the file I/O from the stack serialization:
> 
> on mouseUp
>  put word 2 of the long name of stack "data" into fName
>  replace quote with "" in fName
>  if the shiftKey is "up" then
>    put the long seconds into t0
>    save stack "data"
>    put the long seconds - t0 into t1
>    put "saving data took " && t1 && "seconds" into fld "timeInfo"
>    put 0.000001*(the length of URL ("file:" & fName)) && "MB" into fld "lengthInfo"
>  else
>    put url ("binfile:"&fName) into tData
>    put the long seconds into t
>    put tData into url ("binfile:"& fName)
>    put the long seconds - t
>  end if
> end mouseUp
> 
> So I ran your tool, making a stack with 300 cards, which produces a file a bit over 8MB.  These are my times:
> 
> Ubuntu 18.04 w/SSD
> Stack: 0.097182
> File:  0.008475
> 
> Windows 10 w/HDD
> Stack: 8.183708
> File:  0.014
> 
> Even with the differences in the hardware, it looks like the bottleneck is in the stack serialization, and the file I/O seems good.
> 
> Anyone here in a position to run Neville's test with this modification on similarly-configured systems but different OSes?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> 
> 
> Neville Smythe wrote:
> 
>> Richard
>> Here is a link to the test stack for testing the speed of save stack
>> https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
>> I don’t know why the test stacks I supplied disappeared from the QC bug report.
>> You need the SlowSave.livecode and the data.livecode stacks. They are both small, but SlowSave creates a large stack with 300 cards and the lorem ipsum text data to build an 8 MB stack, and displays the timing for saving. On my MacBook Air it takes 0.13 seconds to save; on Windows 10 installations I have seen times from 3 seconds to 10 seconds.
>> In this test, the stack has just 300 cards, 1 field on each, and lots of ascii text (so there should be no problems converting to utf-8 before saving in the unlikely event that is happening, and in any case would happen on all platforms). I haven’t tested stacks with large numbers of controls or large images rather than large text data.
>> Other apps on Windows 10 certainly don’t display this behaviour, which  indicates it is a LC problem not a Windows problem. Antivirus software and Defender were off during the test. I was under the impression that saving files from LC, rather than stacks, was not slower than normal, but Bob’s recently experience with saving data to a database may contradict that.
>> Some people have had trouble verifying my observations (other LC Forum users have confirmed). QC originally could not confirm the bug until they tried it “on an older PC”. However one of my users recently updated to a *very* fast HP box; it cut the save time down significantly but was still at least 20 times slower than on a typical Mac, ie almost usable. So maybe it has something to do with the Windows installation, though the ones I used were stock standard. I can’t see how fonts could be involved, for example. Neville
> 
> 
> _______________________________________________
> 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