Two questions

[Richard Gaskin]

Thomas J McGrath III wrote:

> I am not used to the send in (time) structure. So, you and Richard are
> suggesting it and it does not use up processor time???
> I remember 'too much recursion' in SC and as such have stayed away from
> complex time loops etc.
> :-) Are you guys sure that 'send in' will actually work without taxing
> the various systems and processors? Cause if I start using it, you know
> I will break it. ;-)

The "send <msg> in <time>" construct isn't using a loop but rather a timer
mechanism similar to Mark Lucas' timer externals for SC.  While there is
some modest overhead internally for keeping track of pending messages it's
happening in highly-optimized compiled C++ code so it's baely measurable at
all.

The bigger processing hit is the time it takes to receive and process a
pending message.  With any such polling mechanism most of the time you will
not do anything, so taking as little time as possible for doing nothing is
critical.

With Rev, testing a "send" command and an "if" statement takes about 0.037
MILLIseconds on my old 500MHz G4.  On my 1.3GHz Celeron it takes takes even
less.

Here's the script I posted that I used to measure the overhead:

on mouseUp
   global gSaveScreenRect
   put the screenRect into gSaveScreenRect
   put 10000 into n
   put the millisecs into t
   --
   repeat n
      send "checkResolution" to me
   end repeat
   --
   put (the millisecs - t ) / n
end mouseUp

on checkResolution
   global gSaveScreenRect
   if the screenrect<> gSaveScreenRect then
      answer "it changed"
   end if
end checkResolution


There are a few limitations Transcript imposes that are different from other
xTalks, such as not being able to overload bult-in commands.  But as you'll
find if you do more benchmarking, such modest sacrifices pay big dividends
in streamlining script execution (when was the last time you read a post
here about a need to overload a built-in command?).

Another big advantage is Transcript's pre-compilation.  Scripts processing
takes two passes:  one to convert the scripting language into efficient
bytecode, and a second to execute the bytecode.  In most xTalks scripts have
no processing done until execution.  But in Transcript (and ToolBook too)
scripts are tokenized into bytecode when the script editor is closed or when
an object is loaded into the message path, so the hardest work is done in
advance of execution.

Moreover, the form of bytecode Transcript uses is said to be more
efficiently structured than even Java's, making execution even faster.

And of course with a 4GL most of the code being executed is highly-optimized
C++, with the scripts being merely glue between these compiled routines.

The net result of these interpreter design elements is a very-high-level
language that in many cases rivals, and sometimes outperforms, lower-level
languages.

And when you add in ultra-effecient language extensions like "repeat for
each" things only get faster.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc