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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
