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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
