Dale,
If I get your drift, YOU are the user and you'll be working with
stacks. Correct? And you really don't have that many really large
stacks? Just a lot of them and a couple of large ones? But even those
fall short of the "magic" 5,000 card number?
Paul's suggestion that you eliminate the stack compaction and all "on
idle" handlers is valid for the reasons explained by others.
With the number of stacks you have, doing "start using" for all of
them is going to take a while, but instead of calling them every now
and then as you find you need them, perhaps you could just load all of
them into memory at the outset when you start working; not something
that could have even been considered before the new Macs with gobs of
RAM. This is going to make everything run fast once you get going.
I think I WOULD consider moving some of the "fixed data" into external
text files that you can easily create with scripting and can be loaded
VERY fast at the outset. I don't have a really good picture as to what
you are doing, but I think you can minimize the rewriting by doing
something like what I've suggested. I think it's going to be difficult
to find out why the HyperSearch isn't working correctly until you have
all of the material it searches converted to Rev and external text
files. Obviously, this isn't going to be done too easily and I'm sure
you'll find some better ways to manage things as you work with over
200 stacks. (whew!)
Good luck,
Joe Wilkins
On Dec 29, 2008, at 1:40 PM, Paul Looney wrote:
Dale Pond wrote:
"In the end I do not see any reason to redesign the collection - way
too much data for that now. If the HyperSearch stack can be made to
work like it did in HC I would be quite happy."
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
