On Tue, 9 Nov 1999, Geoff Canyon wrote:
> Hi, I have some basic questions about MetaCard that I've been pondering
> over the last few days. Most of them are probably Scott questions, but if
> anyone else has any practical experience, feel free to jump in. Here they
> are:
>
> What's the practical limit on the number of cards in a stack? I'm
> assuming that MetaCard's built-in system for storing cards won't actually
> handle, say, forty-two million cards, but how far will it go? Is the
> limit affected by the platform, or the power of the computer? Does
> performance slowly taper off, drop like a stone, or does a pixie pop up
> on screen and tweak your nose when you try to create that last extra card?
>
> Similarly, what's the practical limit on objects on a card? In a
> background? Items in an array? Who's tortured MetaCard the worst? :-)
There are no hard limits on any of these, and the point at which it
slows down too much or fails to run at all depends entirely on how
much memory (RAM and swap) is available on the system. There will be
a huge performance hit when you run out of RAM, and it'll just get
worse as the ratio of RAM to virtual memory usage decreases.
> Just as an example, I've done stacks in HyperCard with several thousand
> cards, with no ill effects, although others have been mortified at my
> daring in doing so. I plan to do similar stacks in MetaCard.
A couple thousand cards is no problem as long as there isn't too much
text on each. The find command can get pretty slow at that size if
there are a lot of fields, though. I'd still recommend not doing this
in MetaCard (nor in HyperCard, for that matter) because you'd be a lot
better served by using a real database for this kind of thing.
> I wrote a project that used a tab-delimited text variable as a database,
> and used lineoffset to find things in it. I found that performance was
> much better if I first processed the variable into hundred-line chunks,
> then did lineoffsets on those. This was the case with anything more than
> a few hundred lines. Does this fit with your experiences with MetaCard?
> Is there a better built-in way? Would an array be faster?
An array would definitely be a lot faster. There's more RAM overhead
when storing things in array, though. But arrays in turn are a lot
more efficient than using cards and fields (putting 10s of thousands
of things in an array is no problem).
> Is there any way to pare down the MetaCard runtime when creating a
> standalone, to only include the things you need? Or is there a way to
> remove the graphical aspects of MetaCard entirely, leaving just the
> MetaTalk engine's ability to process MetaTalk? I'm (idly) thinking of a
> competitor to Perl/Python/Rebol.
There isn't any way to do this now. The engine is structured in such
a way that it'd be pretty easy to build something like this, though.
The engine size would drop by about 50% if we did. But the only
overhead associated with the graphical stuff is just in the size of
your distribution. The graphical doesn't require any more RAM to run
or cost much in terms of performance because the OS only loads the
parts it needs into RAM. The time for initialization of the graphical
stuff is negligible, and isn't done at all on UNIX systems if you
start the engine up with a script instead of with a stack.
Regards,
Scott
> Thanks!
>
> gc
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
