Performance Mystery Solved - IT'S THE DATA STUPID!!

Pete Haworth pete at mollysrevenge.com
Thu Nov 11 20:46:19 EST 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
>copy 
>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
>benchmarks?
>
>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
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution


Pete Haworth
Molly's Revenge
www.mollysrevenge.com



More information about the use-livecode mailing list