My thanks to you and Valentin. Using a property list in the style
[name:memberref], not finding a member now takes 2 milliseconds down from
80. Other than the code to build the list, I only had to change two lines of
code to get my program to work with this new method. This list build time
for ~9000 elements is about 13 secs, not too bad, but I'll take a look at
saving the list to disk.
Thanks again,
Kevan
----- Original Message -----
From: "Jakob Hede Madsen" <[EMAIL PROTECTED]>
To: "Lingo programming discussion list" <[email protected]>
Sent: Monday, February 13, 2006 2:47 PM
Subject: Re: <lingo-l> Finding cast members quickly...
At 12:30 -0800 13/02/06, Kevan Dettelbach wrote:
When the member being sought after exists, the above runs in under a
millisecond, when the member does not exist it takes 80 milliseconds to
not find it.
My guess is that when Director does not find the member in the current
cached member-lookup-table, it rescans all members as a safety-measure,
and that is why it takes so long. I could well be wrong, and it doesn't
matter; the fact is it's slow. The point is just that when you build and
rely upon your own custom database scheme, you can design it to not
exhibit such unwanted behavior.
1. For each level, compile a look-up table to determine which images exist
at that level. Drawback: due to the number of images involved, this
look-up table would be huge, and memory is very tight in this program
already to the number of large images being moved in and out of memory all
the time.
Like Valentin said; in comparison to the amount of memory used for huge
images, the amount needed for a lookup-list should be immaterial.
You could scan through the castlibs and build a propList like so:
[intLevelNum:[intMemberID:memberRef,...],...]
Where intMemberID is something like: (currow * 1000) + curcol
Remember to sort the lists when built, because it increases speed.
In my experience such a scan-build is surprisingly fast, and its a
one-time event when your engine starts.
If the scan-build is to slow for runtime startup you could run it during
authoring, and cache the result. There are a couple of xtras that saves
lists as files, and reestablishes them reeeealy fast.
2. Access the members, using the numerical version of member() i.e.
member(membernum,castnum). This has the added advantage of actually being
faster when the image exists as well. Drawback: The images are sorted by
level into different casts, but are not guarrenteed to be sorted correctly
within those casts. I think they are, but there are thouands of images to
check.
I'm not so hot on this route, but you said you were leaning this way, so:
If the members aren't properly ordered now, then make some authoring-lingo
that moves them according to your liking... then they will be in order.
Sincerely Jakob.
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email
[email protected] (Problems, email [EMAIL PROTECTED]). Lingo-L
is for learning and helping with programming Lingo. Thanks!]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email
[email protected] (Problems, email [EMAIL PROTECTED]). Lingo-L is for
learning and helping with programming Lingo. Thanks!]
