Sorting a large field of data
davidocoker at gmail.com
Mon Mar 10 17:37:49 CDT 2008
Thank you all very much!
The problem with the sort routine is history, so now I'll look around
the code to see if I can improve overall performance. (I appreciate
the link Sarah!)
This might be an uphill battle for the remaining performance issues,
due to the nature of what I'm putting together. Although it's faster
to do all of the processing "behind the scene" in variables and such,
in this case I prefer to allow the user to see most of what's going
on. It's almost mesmerizing to watch this program work in real time,
so the marketing value sems like it might offset the overall speed I
...besides, that leaves the doors open for a "Pro" version a little
later for those that don't want to waste any time. ;)
Thanks again good folks!
On Sun, Mar 9, 2008 at 8:59 PM, Sarah Reichelt <sarah.reichelt at gmail.com> wrote:
> On Mon, Mar 10, 2008 at 11:24 AM, David Coker <davidocoker at gmail.com> wrote:
> > Sure enough, after putting the field into a variable first, it helped a LOT!
> > Thank you very much, Eric!
> > >>>without locking the screen....
> > I'm not I understand exactly *how* to lock the screen before doing my
> > processing and maybe more importantly, what effect does that have on
> > performance?
> Since Eric is probably asleep at this time :-) I thought I would chime in here.
> Locking the screen is a common technique when a large graphical update
> is going to happen e.g. creating, moving or deleting lots of objects
> or changing the data in a large field or many small fields. You just
> issue the command "lock screen". When the handler is finished, it will
> unlock the screen automatically, but if you want the new display to
> appear before then, just use "unlock screen". In certain cases, this
> will cause a dramatic increase in speed as the engine only has to
> display the graphics once rather than after every change.
> Note that the term "lock screen" is rather a misnomer as only the
> current window is actually locked.
> There used to be a HyperCard stack detailing many ways to speed up
> scripts and that helped me a lot. A while ago, I compiled a Revolution
> equivalent which you can find here
> <http://www.troz.net/Rev/tutorials/>. That might give you some more
> ideas on speeding up your scripts.
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode