Arrays in Rev (long)

[Richard Gaskin]

Troy Rollins wrote:

> On Jul 12, 2004, at 11:41 PM, Richard Gaskin wrote:
> 
>> Yes, it takes almost six times longer to access a property than it 
>> does to access a local var. Run the benchmarking script below; on my 
>> modest single-processor G4 it gets:
>>
>> Props: 62 ms
>> Vars:  12 ms
>
> Hmm. Very interesting, my "modest" 1gHz G4 shows the same results for 
> vars exactly, but props ran 274ms... roughly 20 times as long.

Does 0.124ms per access have you tapping your foot with impatience? ;)

I wonder what accounts for the difference.  My PB has an L3 cache, 768MB 
RAM, OS X 10.3.4.  Any other differences we might look at?

> So, it would be safe to say that vars are considerably faster, as Jacque 
> said. But, at least until I learn some new techniques, are way more 
> limited, to my thinking.
> 
> But then, here is something interesting, based on an adaptation of your 
> benchmark script (note that the array even uses a slower repeat 
> structure.) -
> 
> Props: 274
> Vars: 12
> Array: 129
> 
> 
> on mouseUp
>   put 10000 into N
>   --
>   put the millisecs into s
>   repeat n
>     set the uTest of this stack to "hello world"
>     get the uTest of this stack
>   end repeat
>   put the millisecs - s into s1
> 
>   --
>   put the millisecs into s
>   repeat n
>     put "Hello World" into tMyVar
>     get tMyVar
>   end repeat
>   put the millisecs - s into s2
>   --
>   put the milliSecs into s
>   repeat with i = 1 to n
>     put "Hello world" into tMyVar[i]
>     get tMyVar[i]
>   end repeat
>   put the milliSecs - s into s3
> 
>   put "Props: "&s1 &cr& "Vars: "& s2 &CR& "Array: " & s3
> end mouseUp

Storing a single value to overwrite the entire contents of a single var 
will be hard to beat.

But to compare apples to apples more closely, we might modify tests 1 
and 2 to store values indexed by i:

on mouseUp
   put 10000 into N
   --
   put the millisecs into s
   repeat  with i = 1 to n
     set the uTest[i] of this stack to "hello world"
     get the uTest[i] of this stack
   end repeat
   put the millisecs - s into s1

   --
   put the millisecs into s
   repeat  with i = 1 to n
     put "Hello World" into line i of tMyVar
     get line i of tMyVar
   end repeat
   put the millisecs - s into s2
   --
   put the milliSecs into s
   repeat with i = 1 to n
     put "Hello world" into tMyVar[i]
     get tMyVar[i]
   end repeat
   put the milliSecs - s into s3

   put "Props: "&s1 &cr& "Vars: "& s2 &CR& "Array: " & s3
end mouseUp


And here we see that delimited vars don't scale well in indexed accesses:

Props:  165 ms
Vars: 17155 ms
Array:  110 ms

It's interesting to see how close the times are for the object-based 
properties and the variable-based arrays.  This would be jaw-dropping in 
any other xTalk, as most others page objects from disk and you know what 
that does to performance, but just another benefit of the always-in-RAM 
way that Rev deals with stack files.

And all the while, just one line away from being saved to disk if needed.

If the ~40% difference in execution speed is critical (here that amounts 
to 0.0055ms per access), remember you can always store an array into an 
object's custom props if needed:

   put the customProperties of stack tMyStack into tMyArray
   set the customProperties of stack tMyStack to tMyArray

I recently got Vitual PC (so I can build Win installers for clients on 
the train to Monterey, believe it or not), and I find the ability to 
shut it down mid-session and return to the restored session very 
convenient.  It's given me a new appreciation for saving state data, 
something I'll be adding more of to my apps going forward.  After 
working with Virtual PC, my ideal is to get the user back to as close to 
the same state they were in during their last session as possible.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev