Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

On Feb 19, 2010, at 8:52 PM, Jim Bufalini wrote:

> Josh Mellicker wrote:
> 
>> Oops.
>> 
>> I learned coding from an old guy in an alley, that's why. :-)
>> 
>> When a handler is not event driven, but just looping, monitoring
>> something, and keeps calling itself, what is the proper term?
> 
> Recursion or recursive. This is the same as a tight loop because the handler
> never ends until the recursive calling stops. Hence, without waits *with
> messages* you will have a sluggish GUI.

Just FYI, we were using:

if "monitorExternalProcess" is not in the pendingMessages then send 
"monitorExternalProcess" to me in 1 milliseconds

That's why I was calling it a "1 millisecond loop".

Since this only calls itself once at a time, it's not recursive, right?


> Also, you could easily hit the
> recursive limit if the condition you are looking for does not occur as you
> expect, and your program will crash.
> 
> Use instead:
> 
> send "" to me in 1 millisecond
> 
> This will solve all of your problems of allowing the GUI to be responsive
> and avoid hitting the recursion limit.
> 
> One thing to be aware of though, in any case, of using *wait... with
> messages* or sending in time. The time factor is not absolute. If, for
> example, a handler that takes 10 milliseconds to execute is triggered then
> there will be 10 milliseconds between executions of your "in-time loops"
> 
> Aloha from Hawaii,
> 
> Jim Bufalini
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Jim Bufalini]

Josh Mellicker wrote:

> Oops.
> 
> I learned coding from an old guy in an alley, that's why. :-)
> 
> When a handler is not event driven, but just looping, monitoring
> something, and keeps calling itself, what is the proper term?

Recursion or recursive. This is the same as a tight loop because the handler
never ends until the recursive calling stops. Hence, without waits *with
messages* you will have a sluggish GUI. Also, you could easily hit the
recursive limit if the condition you are looking for does not occur as you
expect, and your program will crash.

Use instead:

send "" to me in 1 millisecond

This will solve all of your problems of allowing the GUI to be responsive
and avoid hitting the recursion limit.

One thing to be aware of though, in any case, of using *wait... with
messages* or sending in time. The time factor is not absolute. If, for
example, a handler that takes 10 milliseconds to execute is triggered then
there will be 10 milliseconds between executions of your "in-time loops"

Aloha from Hawaii,

Jim Bufalini

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

Oops.

I learned coding from an old guy in an alley, that's why. :-)

When a handler is not event driven, but just looping, monitoring something, and 
keeps calling itself, what is the proper term?


On Feb 19, 2010, at 7:20 PM, Jim Bufalini wrote:

> BTW, it's the *with messages* that is important. Also, your use of *callback
> loop* is interesting. A callback is a handler that is triggered when a
> callback event occurs, much like a mouseUp handler is triggered on a mouseUp
> event. It's never in a repeat loop.
> 
> Aloha from Hawaii,
> 
> Jim Bufalini
> 
>> -Original Message-
>> From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution-
>> boun...@lists.runrev.com] On Behalf Of Jim Bufalini
>> Sent: Friday, February 19, 2010 4:56 PM
>> To: 'How to use Revolution'
>> Subject: RE: FYI: writing to and reading from fields much faster than
>> locals, globals or custom properties
>> 
>> Josh Mellicker wrote:
>> 
>>> What we found was that when writing and reading a custom property, or
>> a
>>> variable, in a 1 ms loop, other stack windows became "sluggish" -
>> very
>>> difficult to drag by the header bar, very difficult to click buttons
>>> on, rollover states sticking.
>> 
>> Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI
>> becomes unresponsive. It has nothing to do with the actual speed of
>> variables vs. fields. Please add, somewhere in your repeat loop:
>> 
>> wait 0 milliseconds with messages
>> 
>>> When we replaced with writing to and reading a text field on a
>> substack
>>> (still 1ms), the other windows responded perfectly normally, you
>> could
>>> drag and click just like no callback loop was running.
>> 
>> Yes, because here other handlers are starting and stopping and this
>> gives
>> the engine opportunity to intervene.
>> 
>>> So I just ASSUMED the field was "faster". Maybe the truth is that
>>> custom properties , although faster, somehow interfere with normal
>>> mouse-related processes... or maybe what we found was just specific
>> to
>>> our app, although I don't see how that could be.
>> 
>> It's the repeat loop itself without any wait or other handlers being
>> called.
>> 
>>> Anyway, I will do some more tests as soon as I can. I just wanted to
>>> post, in case someone noticed "sluggishness" in an app with a fast
>>> callback loop, my advice is, try fields and see if that fixes it - it
>>> did for us!
>> 
>> Just add the wait into your repeat loop with vars or custom props and
>> you
>> will see it is even faster than fields. ;-)
>> 
>> Aloha from Hawaii,
>> 
>> Jim Bufalini
>> 
>> ___
>> use-revolution mailing list
>> use-revolution@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

> Just add the wait into your repeat loop with vars or custom props and you
> will see it is even faster than fields. ;-)


Will do! Thanks Jim, your message cleared some some things!


On Feb 19, 2010, at 6:55 PM, Jim Bufalini wrote:

> Josh Mellicker wrote:
> 
>> What we found was that when writing and reading a custom property, or a
>> variable, in a 1 ms loop, other stack windows became "sluggish" - very
>> difficult to drag by the header bar, very difficult to click buttons
>> on, rollover states sticking.
> 
> Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI
> becomes unresponsive. It has nothing to do with the actual speed of
> variables vs. fields. Please add, somewhere in your repeat loop:
> 
> wait 0 milliseconds with messages
> 
>> When we replaced with writing to and reading a text field on a substack
>> (still 1ms), the other windows responded perfectly normally, you could
>> drag and click just like no callback loop was running.
> 
> Yes, because here other handlers are starting and stopping and this gives
> the engine opportunity to intervene. 
> 
>> So I just ASSUMED the field was "faster". Maybe the truth is that
>> custom properties , although faster, somehow interfere with normal
>> mouse-related processes... or maybe what we found was just specific to
>> our app, although I don't see how that could be.
> 
> It's the repeat loop itself without any wait or other handlers being called.
> 
>> Anyway, I will do some more tests as soon as I can. I just wanted to
>> post, in case someone noticed "sluggishness" in an app with a fast
>> callback loop, my advice is, try fields and see if that fixes it - it
>> did for us!
> 
> Just add the wait into your repeat loop with vars or custom props and you
> will see it is even faster than fields. ;-)
> 
> Aloha from Hawaii,
> 
> Jim Bufalini
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

> You should also fit some lock/unlock screen into your testing to see how
> that affects your loop/s and processing speed.

Will do, thanks Scott!



On Feb 19, 2010, at 6:35 PM, Scott Rossi wrote:

> Recently, Josh Mellicker wrote:
> 
>> What we found was that when writing and reading a custom property, or a
>> variable, in a 1 ms loop, other stack windows became "sluggish" - very
>> difficult to drag by the header bar, very difficult to click buttons on,
>> rollover states sticking.
>> 
>> When we replaced with writing to and reading a text field on a substack 
>> (still
>> 1ms), the other windows responded perfectly normally, you could drag and 
>> click
>> just like no callback loop was running.
>> 
>> So I just ASSUMED the field was "faster". Maybe the truth is that custom
>> properties , although faster, somehow interfere with normal mouse-related
>> processes... or maybe what we found was just specific to our app, although I
>> don't see how that could be.
>> 
>> Anyway, I will do some more tests as soon as I can. I just wanted to post, in
>> case someone noticed "sluggishness" in an app with a fast callback loop, my
>> advice is, try fields and see if that fixes it - it did for us!
> 
> Do you have any custom drag routines in your stack/s?  Do you update any
> kind of output while the loop is running?
> 
> My guess is your repeat loop is so tight that the writing to the field
> causes a screen update which slows the repeat loop and allows other events
> such as window dragging to take place.  In my experience, a repeat loop will
> only usually down events when updating the screen repeatedly.
> 
> You should also fit some lock/unlock screen into your testing to see how
> that affects your loop/s and processing speed.
> 
> Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, UX Design
> 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Jim Bufalini]

BTW, it's the *with messages* that is important. Also, your use of *callback
loop* is interesting. A callback is a handler that is triggered when a
callback event occurs, much like a mouseUp handler is triggered on a mouseUp
event. It's never in a repeat loop.

Aloha from Hawaii,

Jim Bufalini

> -Original Message-
> From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution-
> boun...@lists.runrev.com] On Behalf Of Jim Bufalini
> Sent: Friday, February 19, 2010 4:56 PM
> To: 'How to use Revolution'
> Subject: RE: FYI: writing to and reading from fields much faster than
> locals, globals or custom properties
> 
> Josh Mellicker wrote:
> 
> > What we found was that when writing and reading a custom property, or
> a
> > variable, in a 1 ms loop, other stack windows became "sluggish" -
> very
> > difficult to drag by the header bar, very difficult to click buttons
> > on, rollover states sticking.
> 
> Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI
> becomes unresponsive. It has nothing to do with the actual speed of
> variables vs. fields. Please add, somewhere in your repeat loop:
> 
> wait 0 milliseconds with messages
> 
> > When we replaced with writing to and reading a text field on a
> substack
> > (still 1ms), the other windows responded perfectly normally, you
> could
> > drag and click just like no callback loop was running.
> 
> Yes, because here other handlers are starting and stopping and this
> gives
> the engine opportunity to intervene.
> 
> > So I just ASSUMED the field was "faster". Maybe the truth is that
> > custom properties , although faster, somehow interfere with normal
> > mouse-related processes... or maybe what we found was just specific
> to
> > our app, although I don't see how that could be.
> 
> It's the repeat loop itself without any wait or other handlers being
> called.
> 
> > Anyway, I will do some more tests as soon as I can. I just wanted to
> > post, in case someone noticed "sluggishness" in an app with a fast
> > callback loop, my advice is, try fields and see if that fixes it - it
> > did for us!
> 
> Just add the wait into your repeat loop with vars or custom props and
> you
> will see it is even faster than fields. ;-)
> 
> Aloha from Hawaii,
> 
> Jim Bufalini
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[J. Landman Gay]

Jim Bufalini wrote:

Josh Mellicker wrote:
 

What we found was that when writing and reading a custom property, or a
variable, in a 1 ms loop, other stack windows became "sluggish" - very
difficult to drag by the header bar, very difficult to click buttons
on, rollover states sticking.


Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI
becomes unresponsive. It has nothing to do with the actual speed of
variables vs. fields. Please add, somewhere in your repeat loop:

wait 0 milliseconds with messages


Exactly what I was thinking. I believe you've nailed it.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Jim Bufalini]

Josh Mellicker wrote:
 
> What we found was that when writing and reading a custom property, or a
> variable, in a 1 ms loop, other stack windows became "sluggish" - very
> difficult to drag by the header bar, very difficult to click buttons
> on, rollover states sticking.

Ahhh...Now THIS makes sense. Your repeat loop is so tight that the GUI
becomes unresponsive. It has nothing to do with the actual speed of
variables vs. fields. Please add, somewhere in your repeat loop:

wait 0 milliseconds with messages

> When we replaced with writing to and reading a text field on a substack
> (still 1ms), the other windows responded perfectly normally, you could
> drag and click just like no callback loop was running.

Yes, because here other handlers are starting and stopping and this gives
the engine opportunity to intervene. 

> So I just ASSUMED the field was "faster". Maybe the truth is that
> custom properties , although faster, somehow interfere with normal
> mouse-related processes... or maybe what we found was just specific to
> our app, although I don't see how that could be.

It's the repeat loop itself without any wait or other handlers being called.

> Anyway, I will do some more tests as soon as I can. I just wanted to
> post, in case someone noticed "sluggishness" in an app with a fast
> callback loop, my advice is, try fields and see if that fixes it - it
> did for us!

Just add the wait into your repeat loop with vars or custom props and you
will see it is even faster than fields. ;-)

Aloha from Hawaii,

Jim Bufalini

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Scott Rossi]

Recently, Josh Mellicker wrote:

> What we found was that when writing and reading a custom property, or a
> variable, in a 1 ms loop, other stack windows became "sluggish" - very
> difficult to drag by the header bar, very difficult to click buttons on,
> rollover states sticking.
> 
> When we replaced with writing to and reading a text field on a substack (still
> 1ms), the other windows responded perfectly normally, you could drag and click
> just like no callback loop was running.
> 
> So I just ASSUMED the field was "faster". Maybe the truth is that custom
> properties , although faster, somehow interfere with normal mouse-related
> processes... or maybe what we found was just specific to our app, although I
> don't see how that could be.
> 
> Anyway, I will do some more tests as soon as I can. I just wanted to post, in
> case someone noticed "sluggishness" in an app with a fast callback loop, my
> advice is, try fields and see if that fixes it - it did for us!

Do you have any custom drag routines in your stack/s?  Do you update any
kind of output while the loop is running?

My guess is your repeat loop is so tight that the writing to the field
causes a screen update which slows the repeat loop and allows other events
such as window dragging to take place.  In my experience, a repeat loop will
only usually down events when updating the screen repeatedly.

You should also fit some lock/unlock screen into your testing to see how
that affects your loop/s and processing speed.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

On Feb 18, 2010, at 4:29 PM, Kay C Lan wrote:

> On Fri, Feb 19, 2010 at 3:21 AM, Richard Gaskin
>  wrote:
>> 
>> Maybe that should be "Benchmark Obsessive". :)
>> 
>> True, I was sleeping at 1AM PST, but when I got up this morning I found this
>> intriguing enough to pull out one of my old test stacks.  In fact, while I
>> was at it I took some notes for an article on benchmarking I've been itching
>> to write and posted it to revJournal:
>> 
> Hmmm, maybe 'Benchmark Obsessive Compulsive' ;-)
> 
> Using Richard's stack:
> 
> 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 = true
> 
> Results:
> Visible field, current card:  24
> Hidden field, current card:   22
> Visible field, unopened card: 13
> Hidden field, unopened card:  14
> Custom property:  4
> Global variable:  2
> Local variable:   1
> 
> 
> Number of iterations for read/write access: 5000
> LockScreen = false
> LockMessages = false
> 
> Results:
> Visible field, current card:  2367
> Hidden field, current card:   2856
> Visible field, unopened card: 15
> Hidden field, unopened card:  14
> Custom property:  37
> Global variable:  2
> Local variable:   1
> 
> 
> So very similar results.
> 
> Josh, we are waiting ???



Just to reiterate:

What we found was that when writing and reading a custom property, or a 
variable, in a 1 ms loop, other stack windows became "sluggish" - very 
difficult to drag by the header bar, very difficult to click buttons on, 
rollover states sticking.

When we replaced with writing to and reading a text field on a substack (still 
1ms), the other windows responded perfectly normally, you could drag and click 
just like no callback loop was running.

So I just ASSUMED the field was "faster". Maybe the truth is that custom 
properties , although faster, somehow interfere with normal mouse-related 
processes... or maybe what we found was just specific to our app, although I 
don't see how that could be.

Anyway, I will do some more tests as soon as I can. I just wanted to post, in 
case someone noticed "sluggishness" in an app with a fast callback loop, my 
advice is, try fields and see if that fixes it - it did for us!





___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

On Feb 17, 2010, at 10:44 PM, Jim Ault wrote:

> 
> 
> 
> On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote:
> 
>> You all probably know this, but thought I would share our experience anyway:
>> 
>> We are working on a project with a 1 millisecond callback loop that 
>> communicates with an external process in a performance-critical application, 
>> and when prototyping, temporarily used some fields on a card to write and 
>> read values from during the loop.
>> 
>> 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.
>> 
>> It took a while to figure out the culprit, but once we went line by line 
>> from our original prototype script, wee found that going back to reading and 
>> writing to a field made everything work smoothly again!
>> 
>> Then we tried local, then a global variable... not good... same result as 
>> custom properties.
>> 
>> So if you are writing an app where performance is critical, Rev reads and 
>> writes to fields super fast!___
> 
> 
> Something does not seem to be correct in this instance.

I know, I've always had the impression fields were slower.

> 
> Which version of Rev?  Which platform?

The latest, Mac 10.6.2

> Is the flag "script debug mode" set to false?

no

> Are there any pending messages in the queue?

The callback handler calls itself:

if "monitorExternalProcess" is not in the pendingMessages then send 
"monitorExternalProcess" to me in 1 milliseconds


> Front scripts? back scripts?

no

> 
> I have done many performance-critical event loops using variables and custom 
> properties in networking apps between computers and offices.  Whenever I 
> encounter a slow down, I look at my error trapping loops or status detection 
> code and find that I have added clock cycles by not programming properly.
> 
> If you have discovered something that affects the performance so that fields 
> are noticeably faster, then we need to know what is happening.  I have never 
> tested fields to be as fast or faster than custom properties, especially for 
> larger blocks of text (such as whole web page HTML)
> 
> Please, when you have time, provide a little more feedback.

I will, we need to get this revision out the door, then I will try and do some 
more tests.


> 
> Jim Ault
> Las Vegas
> 
> 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Josh Mellicker]

On Feb 17, 2010, at 10:02 PM, Jan Schenkel wrote:

> --- On Wed, 2/17/10, Josh Mellicker  wrote:
>> You all probably know this, but
>> thought I would share our experience anyway:
>> 
>> We are working on a project with a 1 millisecond callback
>> loop that communicates with an external process in a
>> performance-critical application, and when prototyping,
>> temporarily used some fields on a card to write and read
>> values from during the loop.
>> 
>> 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.
>> 
>> It took a while to figure out the culprit, but once we went
>> line by line from our original prototype script, wee found
>> that going back to reading and writing to a field made
>> everything work smoothly again!
>> 
>> Then we tried local, then a global variable... not good...
>> same result as custom properties.
>> 
>> So if you are writing an app where performance is critical,
>> Rev reads and writes to fields super
>> fast!
> 
> If the field you're using to set/get data, is _invisible_ then it makes sense 
> that this would be faster than set/get data using a custom property: built-in 
> properties don't have to traverse the message hierarchy for setProp/getProp 
> handlers, and an invisible field doesn't have to redraw itself.
> Why it would be faster than global/local variable access, is a puzzler - are 
> you using arrays or storing the text in the same 'flat' way as field text?


I never tried arrays, just global, local, custom property and a text field.


> 
> Jan Schenkel
> =
> Quartam Reports & PDF Library for Revolution
> 
> 
> =
> "As we grow older, we grow both wiser and more foolish at the same time."  
> (La Rochefoucauld)
> 
> 
> 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Kay C Lan]

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

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Kay C Lan]

On Fri, Feb 19, 2010 at 3:21 AM, Richard Gaskin
 wrote:
>
> Maybe that should be "Benchmark Obsessive". :)
>
> True, I was sleeping at 1AM PST, but when I got up this morning I found this
> intriguing enough to pull out one of my old test stacks.  In fact, while I
> was at it I took some notes for an article on benchmarking I've been itching
> to write and posted it to revJournal:
>
Hmmm, maybe 'Benchmark Obsessive Compulsive' ;-)

Using Richard's stack:

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 = true

Results:
Visible field, current card:24
Hidden field, current card: 22
Visible field, unopened card:   13
Hidden field, unopened card:14
Custom property:4
Global variable:2
Local variable: 1


Number of iterations for read/write access: 5000
LockScreen = false
LockMessages = false

Results:
Visible field, current card:2367
Hidden field, current card: 2856
Visible field, unopened card:   15
Hidden field, unopened card:14
Custom property:37
Global variable:2
Local variable: 1


So very similar results.

Josh, we are waiting ???
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Richard Gaskin]

At 03:09:01 CST 2010 Kay C Lan wrote:


On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote:


Rev reads and

writes to fields super fast!




Clearly Richard 'the Benchmark King' Gaskin is asleep right now, but
when he wakes I'm sure he'll have the figures.


Maybe that should be "Benchmark Obsessive". :)

True, I was sleeping at 1AM PST, but when I got up this morning I found 
this intriguing enough to pull out one of my old test stacks.  In fact, 
while I was at it I took some notes for an article on benchmarking I've 
been itching to write and posted it to revJournal:


Benchmarking Performance in RevTalk


Using this exercise of data access as an example, the code, results, and 
downloadable stack are in this section:



The bottom line in my tests reflect Dr. Raney's comments that Jacque noted:

Number of iterations for read/write access: 5000
LockScreen = true
LockMessages = true

Results:
Visible field, current card:  22
Hidden field, current card:  23
Visible field, unopened card:  13
Hidden field, unopened card:  14
Custom property:  5
Global variable:  1
Local variable:  2


Number of iterations for read/write access: 5000
LockScreen = false
LockMessages = false

Results:
Visible field, current card:  3353
Hidden field, current card:  4823
Visible field, unopened card:  13
Hidden field, unopened card:  14
Custom property:  13
Global variable:  2
Local variable:  1


One of the challenges in attempting to determine performance within a 
complex system is that there's so much going on that can affect things.


Benchmarking specific elements in isolation removes most of those 
interactions, usually leading to more repeatable results.


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

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Peter Alcibiades]

It must be the first mistake you make when writing your first Rev program -
at least, it was mine.  On an old used donated celeron, I had written a
script that went through several thousands of lines and extracted sub totals
from tab delimited fields.  As the file increased in size, the computation
slowed down.  I was of course doing it in fields.  Finally when it was
starting to take minutes, I put in a button that said 'just look at the
report, don't redo it'!  The things we think of! 

In the end, I discovered that you should sum the subtotals into variables
and then put the variables into the fields, and it became almost instant.

So this seems like a very easy thing to test, just generate 20k lines of
numbers and do some totals into fields and also alternatively into a
variable and then put into the same fields.  The difference in my experience
on a slow machine was, literally, a matter of minutes.
-- 
View this message in context: 
http://n4.nabble.com/FYI-writing-to-and-reading-from-fields-much-faster-than-locals-globals-or-custom-properties-tp1559633p1560686.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[J. Landman Gay]

J. Landman Gay wrote:

Dr. Raney once told me speed was in this order:

global variables
local variables
custom properties
fields


I should amend that. I'm not positive about the order of the first two. 
I might have them reversed. What I am sure about is that variables are 
faster than properties, which are faster than fields.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[J. Landman Gay]

Kay C Lan wrote:


Obviously you are not experiencing normal so many of us here would be
very interested in more details to understand why. And if I were a
betting man, I'd be putting my money on the end result will be using
Globals will be the fastest option for you.


Agreed. Dr. Raney once told me speed was in this order:

global variables
local variables
custom properties
fields

So I too would like to know what the situation is where fields could 
possibly be faster than the other options. If the field is hidden or the 
IDE is not running (i.e., a CGI,) I might be able to see that fields 
could be as fast as custom properties since most of the overhead of 
writing to fields involves the drawing routines. But it shouldn't be 
faster than variables.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Kay C Lan]

> On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote:
>
Rev reads and
>> writes to fields super fast!
>

Clearly Richard 'the Benchmark King' Gaskin is asleep right now, but
when he wakes I'm sure he'll have the figures. The best I could track
down was some benchmarking Richard did a while back comparing Globals,
Custom Property's and Functions. His test was a simple one liner
repeated 1 million times, the results were (in milliseconds):

Global:   0.00023
Property: 0.00151
Function: 0.00198

So whilst it is good to know that Rev can read and write into fields
in under a 1 millisecond, and you may consider that super fast,
NORMALLY using Globals or Custom Properties will result in a speed
increase of several orders of magnitude.

Obviously you are not experiencing normal so many of us here would be
very interested in more details to understand why. And if I were a
betting man, I'd be putting my money on the end result will be using
Globals will be the fastest option for you.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Jim Ault]

On Feb 17, 2010, at 8:10 PM, Josh Mellicker wrote:

You all probably know this, but thought I would share our experience  
anyway:


We are working on a project with a 1 millisecond callback loop that  
communicates with an external process in a performance-critical  
application, and when prototyping, temporarily used some fields on a  
card to write and read values from during the loop.


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.


It took a while to figure out the culprit, but once we went line by  
line from our original prototype script, wee found that going back  
to reading and writing to a field made everything work smoothly again!


Then we tried local, then a global variable... not good... same  
result as custom properties.


So if you are writing an app where performance is critical, Rev  
reads and writes to fields super fast! 
___



Something does not seem to be correct in this instance.

Which version of Rev?  Which platform?
Is the flag "script debug mode" set to false?
Are there any pending messages in the queue?
Front scripts? back scripts?

I have done many performance-critical event loops using variables and  
custom properties in networking apps between computers and offices.   
Whenever I encounter a slow down, I look at my error trapping loops or  
status detection code and find that I have added clock cycles by not  
programming properly.


If you have discovered something that affects the performance so that  
fields are noticeably faster, then we need to know what is happening.   
I have never tested fields to be as fast or faster than custom  
properties, especially for larger blocks of text (such as whole web  
page HTML)


Please, when you have time, provide a little more feedback.

Jim Ault
Las Vegas



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[Jan Schenkel]

--- On Wed, 2/17/10, Josh Mellicker  wrote:
> You all probably know this, but
> thought I would share our experience anyway:
> 
> We are working on a project with a 1 millisecond callback
> loop that communicates with an external process in a
> performance-critical application, and when prototyping,
> temporarily used some fields on a card to write and read
> values from during the loop.
> 
> 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.
> 
> It took a while to figure out the culprit, but once we went
> line by line from our original prototype script, wee found
> that going back to reading and writing to a field made
> everything work smoothly again!
> 
> Then we tried local, then a global variable... not good...
> same result as custom properties.
> 
> So if you are writing an app where performance is critical,
> Rev reads and writes to fields super
> fast!

If the field you're using to set/get data, is _invisible_ then it makes sense 
that this would be faster than set/get data using a custom property: built-in 
properties don't have to traverse the message hierarchy for setProp/getProp 
handlers, and an invisible field doesn't have to redraw itself.
Why it would be faster than global/local variable access, is a puzzler - are 
you using arrays or storing the text in the same 'flat' way as field text?

Jan Schenkel
=
Quartam Reports & PDF Library for Revolution


=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)


  

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties

[stephen barncard]

That is counter to what we've been taught was the case previously. In
previous versions the field overhead was far greater than CPs. Perhaps it's
the multi-dimensional aspect.
-
Stephen Barncard
San Francisco
http://houseofcubes.com/disco.irev


On 17 February 2010 20:10, Josh Mellicker  wrote:

> You all probably know this, but thought I would share our experience
> anyway:
>
> We are working on a project with a 1 millisecond callback loop that
> communicates with an external process in a performance-critical application,
> and when prototyping, temporarily used some fields on a card to write and
> read values from during the loop.
>
> 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.
>
> It took a while to figure out the culprit, but once we went line by line
> from our original prototype script, wee found that going back to reading and
> writing to a field made everything work smoothly again!
>
> Then we tried local, then a global variable... not good... same result as
> custom properties.
>
> So if you are writing an app where performance is critical, Rev reads and
> writes to fields super fast!___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution