In article <cs.unm.edu>,
Keith Wiley <unm.edu> wrote:
Well, first off, it isn't faster. At best, BlockMove runs at the same
speed your own "grab an element, stuff an element" loop would. At worst,
it takes a substantial hit due to several factors, including memory
caching, virtual versus "real" memory, and so on. Quite a few different
things go into figuring out exactly what the performance is actually
going to be on a particular machine.
Using the toolbox, NewPtrClear(Size) will (ignoring the possibility of
an Out Of Memory error) hand you back a pointer to a block of zeroed
memory "Size" bytes long. But I guarantee you that it's zeroing that
block exactly like you would: one element at a time.
Regardless of what kind of "wrapper" gets put around it, in *EVERY*
case, zeroing a block of memory boils down to a construct that's
essentially identical to the following:
Block[X++] = 0;
There might be some "setup" done to check for a valid range, and
similar, but the "guts" of the routine is going to look very much like
that shown above, regardless of what "bells and whistles" have been
grafted onto it.
It's possible, with "wide data" machines (By "wide data", I mean a
machine that ships more than one byte down the wires for a single write
cycle) to do something like:
long MyZero = 0L;
and replace the "Block[X++]" line above with something like:
Block[X+=4] = MyZero;
to allow you to zero 4 bytes at once (Assuming the machine's concept of
a "long" is four contiguous memory locations), but that's something of a
special case, and is, of course, machine-dependent.
Don Bruder - net <--- Preferred Email - SpamAssassinated.
Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
I will choose a path that's clear: I will choose Free Will! - N. Peart
Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>