home *** CD-ROM | disk | FTP | other *** search
- From: Henry.M..Halff@p932.f70.n109.z1.fidonet.org (Henry M. Halff)
- Sender: Uucp@blkcat.UUCP
- Path: sparky!uunet!blkcat!Uucp
- Newsgroups: comp.sys.mac.hypercard
- Subject: Help needed for container search!!!
- Message-ID: <715979162.F00002@blkcat.UUCP>
- Date: Mon, 07 Sep 1992 13:46:54 -0500
- Lines: 33
-
- Mark C. Langston to All about "Help needed for container search!!!" at 1:41:18
- AM on 9/7/92
-
- MC> The user selects a boldface word group from the main field, and the
- MC> background script searches through a container for the selected word
- MC> group, so it can display a set of branching options to the user in the
- MC> 2 smaller fields.
- MC>
- MC> I'm currently using an XFCN called SEARCH to do this, but there is a
- MC> problem: it seems to be dreadfully slow when searching (the
- MC> containers are quite large, on the order of several thousand words to
- MC> search through, each with their respective data structures for
- MC> branching options.)
- MC>
- MC> The entire process should (due to experimental and theoretical
- MC> boundaries) take place in roughly 30 seconds. However, one could
- MC> easily see how the script could take much longer, if the desired word
- MC> is at the bottom of a 3000+ word list in a container.
-
- Your XFCN may be the culprit here. I created a 3000 word global (one word per
- line) and measured the amount of time that it took HyperCard's offset function
- to find a randomly generated target in the list. The average turns out to be
- less than 1/2 tick (actually about .42 ticks) on my IIci. The conditions aren't
- exactly the same as yours, but the result suggests that the straightforward
- approach could be faster.
-
- Here are some suggestions for speeding things up.
-
- 1. Increase memory allocation for HyperCard.
-
- 2. Make sure that your containers are variables, not fields.
-
- 3. Sort the containers so that you can do a binary search.
-