Finding cast members quickly...

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" <hedeimage.dk>
To: "Lingo programming discussion list"
<lingo-llists.fcgnetworks.net>
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.penwor
ks.com/lingo-l.cgi  To post messages to the list, email 
> lingo-lpenworks.com  (Problems, email owner-lingopenworks.com). 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.penwor
ks.com/lingo-l.cgi  To post messages to the list, email
lingo-lpenworks.com  (Problems, email owner-lingopenworks.com). Lingo-L is for learning and helping
with programming Lingo.  Thanks!]