custom properties

[Richard Gaskin]

Kay C Lan wrote:

 > On Thu, Feb 18, 2010 at 12:10 PM, Josh Mellicker wrote:
 >>
 >> Then, while buttoning things up, instead of fields, we switched
 >> to reading and writing a custom property.
 >>
 >> Suddenly, everything went sluggish - you had to click on a button
 >> several times to trigger it, you could barely move stack windows,
 >> etc.
 >
 > Actually, using Richard's benchmark stack, I consistently get
 > customProperties slower than fields if the LockMessages is false and
 > the LockScreen is true.
 >
 > MBP 17" 2.16 GHz, 2GB RAM
 > OS X.6.2, Rev 4.0.0 Build 950
 >
 > Number of iterations for read/write access: 5000
 > LockScreen = true
 > LockMessages = false
 >
 > Results:
 > Visible field, current card: 	23
 > Hidden field, current card: 	22
 > Visible field, unopened card: 	14
 > Hidden field, unopened card: 	14
 > Custom property: 	37
 > Global variable: 	2
 > Local variable: 	1
 >
 > If Josh was using such a set-up, with fields on an unopened card,
 > that's a significant performance hit to move to customProperties.

While his description suggests a difference greater than we see in your 
results, I think you may have stumbled across a useful distinction here:

When I wrote this I was unable to get the results you posted, but since 
your system config is very similar to mine and our other results were 
almost exact matches, I figured the must be a way for me to be able to 
reproduce your results.

Then I figured it out:  You're not running my custom IDE. :)

In my IDE, forked from MC, it follows MC's tradition of lean message 
handling; it's a very close match to the runtime environment, more 
closely matching behavior of standalones. In contrast, Rev's IDE has a 
number of setProp and getProp handlers in its front and backscripts. 
Once I ran my test in the Rev IDE I was able to get results like yours 
with those settings.

Since everything else is the same except for the getProp and setProp 
handlers elsewhere in the environment, there would seem to be a 
relationship between the number of such handlers in the message path and 
the performance of property accesses, even for properties completely 
unrelated to those handled by the getProp and setProp handlers (looks 
like an opportunity for optimization).

I haven't tried this out yet, but I wonder if one had a 
setProp/getProp-rich message path whether it would slow down performance 
as much as described.

But even then, none of this explains how variables could appear slower.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv