Performance Mystery Solved - IT'S THE DATA STUPID!!
pete at mollysrevenge.com
Thu Nov 11 19:46:19 CST 2010
I guess my experience suggests strongly that the stack doesn't stay in memory but I can't prove it. Is there something I can write to my debug log that would help prove this one way or the other?
"Richard Gaskin" <ambassador at fourthworld.com> wrote:
>Monte Goulding wrote:
> >> Unless you're explicitly purging the stacks, any access to
> >> a property of a stack file will load it into memory. The
> >> first access will take a hit only if the stack isn't already
> >> in memory, but subsequent accesses should be about as fast
> >> whether referring to just the stack name or the stack file
> >> path, since they're interchangeable for mainstacks.
> > I don't think this is entirely true. At least it wasn't when
> > I was working on the standalone builder all those years ago.
> > There was a massive difference in speed between looping over
> > the controls of a stack if that stack was invisible toplevel
> > compared to just referencing it as a filename. There was a
> > user that was having extremely slow builds because they had
> > so many controls.
>It would make me very happy if that were the case.
>A couple years ago there was a long thread here in which I complained
>that if I access a property in a stack but don't explicitly open the
>stack, IMO the behavior should be as it was in SuperCard: the stack
>file is read into memory to obtain the property value, and then the
>in memory is disposed of.
>What was happening instead is that the stack file was hanging out in
>memory just the same as if I had opened it, and many here argued that
>that was a good thing.
>I haven't tested this myself in a long time - got any current
>If the behavior has changed then Trevor, Chipp, Jacque, and a good many
>others who voiced an opinion that leaving it in memory was valuable may
>not like it, but I'll be quite happy indeed. :)
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
More information about the use-livecode