Re: METAL is now FREE!!!!!!

[fnet@backus.cba.csuohio.edu (Greg Boh)]

In article <m0nghEz-00007IC@crash.cts.com> beta@gnh-cathouse.cts.com (Scott Sidley) writes:
>> You have to understand that FutureVision contains about 35 TIMES more code
>> than a standard GBBS. So naturally, it will execute slower. It's taking on a

Miss wording here. Replace 'will execute slower' with 'will appear to execute
slower to the end user because of increased demand on the system.'

>> HELL of a lot more responsibilities. 
>
>
>I fail to see why more code has to run slower.  More functions executed in
>order would of course mean that results take longer, but I still fail to see
>why the code would be slower just because its larger.

The code does not execute slower. To the user, it appears to be slower becuase
MORE code is executed to allow more flexibilty.

Because FutureVision has much more functions than GBBS, it has more files to
check, henceforth more instructions to execute. Consequently, the demand on
the system are higher.

A simple thing such as pressing a key at the menu prompt...

Under GBBS, it simply checks the key against an input list.

Under FutureVision, it checks the command, if no command in menu it checks to
see if keywords are active, if so it compares the command to the keywords,
determines if the user has access to the keyword, finds the appropriate CIB
and launches it. (This allows you to hop directly to a menu prompt by a
command. Say, in the message base, you type "GO MOSES" and your taken
directly to the File Transfer prompt. If used properly, you can get around FV
VERY fast.)

The amount of instructions in the ACOS code may be let's say...40, while the
amount of instructions executed under METAL could be upwards of 150.
(These are estimates, but it is just intended to make a point.)

Naturally, the code may "appear" to operate slower to the end user. But when
one looks at how many more instructions METAL is executing behind the scenes a
broader picture is formed.