Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties
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 thisHandlerName 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
On Feb 17, 2010, at 10:02 PM, Jan Schenkel wrote: --- On Wed, 2/17/10, Josh Mellicker j...@dvcreators.net 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 http://www.quartam.com = 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
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
On Feb 18, 2010, at 4:29 PM, Kay C Lan wrote: On Fri, Feb 19, 2010 at 3:21 AM, Richard Gaskin ambassa...@fourthworld.com 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
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 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
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
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
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
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
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 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 thisHandlerName 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
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
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
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
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
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 http://www.revjournal.com/tutorials/benchmarking-revtalk.html Using this exercise of data access as an example, the code, results, and downloadable stack are in this section: http://www.revjournal.com/tutorials/benchmarking-revtalk.html#example 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
On Fri, Feb 19, 2010 at 3:21 AM, Richard Gaskin ambassa...@fourthworld.com 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
On Thu, Feb 18, 2010 at 12:10 PM, Josh Mellicker j...@dvcreators.net 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
FYI: writing to and reading from fields much faster than locals, globals or custom properties
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
Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties
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 j...@dvcreators.net 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
Re: FYI: writing to and reading from fields much faster than locals, globals or custom properties
--- On Wed, 2/17/10, Josh Mellicker j...@dvcreators.net 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 http://www.quartam.com = 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
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
