Go to card has become slow

Richard Gaskin ambassador at fourthworld.com
Thu Apr 9 02:16:57 EDT 2020


Neville Smythe wrote:

 > I have updated the SlowSave test stack with Richard's enhancement to
 > also show the time to save the binary data (no need to use the shift
 > button)
 >
 > https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
 >
 > Pleased to see everyone is seeing the problem at last, it doesn’t seem
 > to be related to the particular Windows 10 installation. But 38
 > seconds for 8 MB!!

Yes, the difference is quite pronounced.

Thank you for updating the stack.

Brian Milby's comment was most illuminating:

    Internally, each object is serialized and written to the
    file buffer in turn.  So the question then becomes how
    much of the difference is due to writing the file in
    pieces compared to the process of serializing the data.


I just did a search at DuckDuckGo for "difference in write speed windows 
vs mac programming":

https://stackoverflow.com/questions/48356177/c-program-runs-much-slower-on-windows-vs-linux-when-doing-file-operations


Among the first results was this discussion from stack overflow, where 
the problem is described as:

   When you execute a build operation with ChatScript, it scans
   all the script files that comprise your chat-bot. In my case,
   that's hundreds of files. This process takes nearly 30 times
   longer on Windows 8.1 than it does on Ubuntu 16.04. Therefore
   I do use Linux for much of my work, but there is a part of
   my work that I have to do on Windows because of certain
   associated tools, so I would like to modify the code base so
   that Windows ChatScript compiles are as fast as on Linux.

   Can anyone think of a reason the code would run so much slower
   on Windows vs. Linux? Are there some C++ file operation codes
   (read/write/etc.) that are known to be much slower on Windows
   compared to Linux due to variances in the C++ run-time libraries
   running on each platform?

Sounds kinda like us, no?

But it gets better.

The first reply suggests a few common things to speed up disk I/O, like 
defragging and double-checking compiler options, but then he kinda gives 
up and says, "But doing all those things for me has never got the 
Windows compile to be quicker than on linux using equivalent disk 
hardware, not once."

Better still, see the last comment on that page. :)

It kinda fits Brian's observation about how the stack file is written in 
a series of small writes, one per object.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com






More information about the use-livecode mailing list