Go to card has become slow
brian at milby7.com
Sat Apr 11 00:48:24 EDT 2020
I just ran another set of tests with a much smaller image.
Text: 5.85s / 0.032s / 8.183708MB
Image: 0.211s / 0.034s / 9.29539MB
One other thing to try tomorrow is to use an individual text field on each
card instead of a shared group. I tried to download the update, but still
got the original version. I could put mine up on GitHub with permission.
On Fri, Apr 10, 2020 at 10:54 PM Neville Smythe via use-livecode <
use-livecode at lists.runrev.com> wrote:
> > On 11 Apr 2020, at 2:00 am, Brian Milby wrote
> > I just imported a 500kb image to the card, removed the text from the
> > created 300 cards.
> > 0.756 seconds normal (171MB). 1.124 from a variable. (image instead of
> > text)
> > 8.311 seconds normal (8.2MB). 0.047 from a variable. (original text)
> > I'll need to clean this up with a better image (something I can share)
> > try on my Mac for comparison when I get off today, but this points
> > at the serialization of the field object being the difference.
> I am intrigued by the fact that save stack (for a stack with on-disk file
> size 171MB) took *less* time than saving its binary data representation.
> Doesn’t that mean that the images were already on disk, and the in-memory
> stack was very much smaller than 171 MB, containing only image references.
> In which case I’m not sure we are comparing like with like, as compared
> with the text version (unless "save stack as newStackFile" might be give
> more comparable info?).
> My hunch is that Richard’s point about the Windows write-to-file overhead
> is still the key, not the serialisation. One would to need to compare the
> number of writes used by the engine for the two stack versions. That I do
> not know how to do , but I think the incomparable Brian could do it!
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode