Re: why are custom properties so fast?
On 14 May 2005, at 2:52 PM, Richard Gaskin wrote: Compared to a field nearly anything else will be faster because of the overhead associated with all the other things fields have to do to display text in addition to storing it. This topic has come up a few times lately, so I decided it was time to do some timing tests :-) I had a field with 1000 lines of data put into a variable, then put the variable back into the field 50 times. Then I did the same with a custom property, first getting the test data from the field (so it was identical) then setting getting the property repeatedly. The fastest method was using a custom property with messages locked. Here are my test results: using a field 740 ticks using a field (with locked screen) 405 ticks using a field from sub stack230 ticks using a field from a sub stack locking the screen 235 ticks The sub-stack's window was not open for these tests. Opening it made the times the same as for a field on the stack running the tests. To get meaningful data for the custom property tests, I had to do 500 repeats, instead of just 50! But dividing my average results then by 10, I got: using a custom property 1.9 ticks using a custom property with messages locked0.3 ticks This is almost 2500 times faster than the field method! Removing the scroll bar from the field had almost no effect. I really didn't expect to come up with such a big difference, but I expect it will only change my habits in certain circumstances. I like the convenience of being able to see my data when necessary so tend to use the closed sub-stack method. However if you have a vast amount of data to shuffle around and it needs to be done fast, this is a good method to remember. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
Sarah, Did you try also with a hidden field? cheers Xavier On 17.05.2005 08:26:40 use-revolution-bounces wrote: On 14 May 2005, at 2:52 PM, Richard Gaskin wrote: Compared to a field nearly anything else will be faster because of the overhead associated with all the other things fields have to do to display text in addition to storing it. This topic has come up a few times lately, so I decided it was time to do some timing tests :-) I had a field with 1000 lines of data put into a variable, then put the variable back into the field 50 times. Then I did the same with a custom property, first getting the test data from the field (so it was identical) then setting getting the property repeatedly. The fastest method was using a custom property with messages locked. Here are my test results: using a field 740 ticks using a field (with locked screen) 405 ticks using a field from sub stack 230 ticks using a field from a sub stack locking the screen235 ticks The sub-stack's window was not open for these tests. Opening it made the times the same as for a field on the stack running the tests. To get meaningful data for the custom property tests, I had to do 500 repeats, instead of just 50! But dividing my average results then by 10, I got: using a custom property1.9 ticks using a custom property with messages locked 0.3 ticks This is almost 2500 times faster than the field method! Removing the scroll bar from the field had almost no effect. I really didn't expect to come up with such a big difference, but I expect it will only change my habits in certain circumstances. I like the convenience of being able to see my data when necessary so tend to use the closed sub-stack method. However if you have a vast amount of data to shuffle around and it needs to be done fast, this is a good method to remember. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution - Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
Sarah Reichelt wrote: Here are my test results: using a field740 ticks using a field (with locked screen)405 ticks using a field from sub stack230 ticks using a field from a sub stack locking the screen235 ticks The sub-stack's window was not open for these tests. Opening it made the times the same as for a field on the stack running the tests. To get meaningful data for the custom property tests, I had to do 500 repeats, instead of just 50! But dividing my average results then by 10, I got: using a custom property1.9 ticks using a custom property with messages locked0.3 ticks This is almost 2500 times faster than the field method! Excellent tests, Sarah. No one seems to enjoy reading my two buckets analogy as much as I did writing it, but having started once down the road of writing an xTalk-like system in C it really does an okay job in describing the field overhead difference. :) I really didn't expect to come up with such a big difference, but I expect it will only change my habits in certain circumstances. I like the convenience of being able to see my data when necessary so tend to use the closed sub-stack method. However if you have a vast amount of data to shuffle around and it needs to be done fast, this is a good method to remember. When I need to access data in properties often, I tend to use my 4W Props tool because it lets me see values at a glance and edit them with a double-click. Sometimes I need to make tools for clients to work with property values, and in most cases crafting a simple palette window to display those takes only a few minutes. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
[EMAIL PROTECTED] wrote: Did you try also with a hidden field? In my earlier tests the times for a hidden field were not much different than for a visible one. Tuviah that the bigger difference is whether a field is on an open card or not, as even hidden fields on open cards are initialized with the same overhead stuff as visible fields (in case they're to be shown). Her tests seem to support Tuv's explanation: using a field 740 ticks using a field from sub stack 230 ticks -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast? RAM?
--- Sarah Reichelt [EMAIL PROTECTED] wrote: using a custom property 1.9 ticks using a custom property with messages locked 0.3 ticks This is almost 2500 times faster than the field method! so is the custom property in RAM and the field contents on the hard drive? [EMAIL PROTECTED]http://www.erikhansen.org __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast? RAM?
Erik Hansen wrote: --- Sarah Reichelt [EMAIL PROTECTED] wrote: using a custom property 1.9 ticks using a custom property with messages locked 0.3 ticks This is almost 2500 times faster than the field method! so is the custom property in RAM and the field contents on the hard drive? When a stack is opened, the whole thing is in RAM, field properties and all. The difference is the overhead associated with each storage mechanism: While fields appear to us to be simple to work with, that's all smoke and mirrors -- under the hood the engine's doing a lot of work setting up storage for style runs, calulating visual line breaks, interacting with the OS font routines, etc. In contrast, all a property does is hold the data. While arguably too lengthy to be considered good writing, the two buckets analogy describes the relative difference in what's going on under the hood: http://lists.runrev.com/pipermail/use-revolution/2005-March/052967.html -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
[EMAIL PROTECTED] wrote: Did you try also with a hidden field? I have now :-) For the same test, hiding the field first brought the time down to about 500 ticks i.e. not as fast as just locking the screen. When using the sub-stack, it made no difference. BTW, in case anyone actually tries the tests and decided my computer is really slow, I actually did 500 repeats with fields and 5000 with custom properties :-) Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
Maybe we should make a machine benchmark stack to test all the rev features across all platforms and cpu configurations... Another use for an sql engine maybe (although Im working on an alternative and this Sarah's benchmark may change lots of my plans - for the better of performance naturally. One issue that seems evident now is that if we store styled text in a field and need to save that to a custom prop, there's 1) loss of data possible (the rev-html converter - or rather stripper), 2) the overhead of saving extra style tags... Just a thought cheers Xavier On 17.05.2005 09:05:14 use-revolution-bounces wrote: [EMAIL PROTECTED] wrote: Did you try also with a hidden field? I have now :-) For the same test, hiding the field first brought the time down to about 500 ticks i.e. not as fast as just locking the screen. When using the sub-stack, it made no difference. BTW, in case anyone actually tries the tests and decided my computer is really slow, I actually did 500 repeats with fields and 5000 with custom properties :-) Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution - Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
[EMAIL PROTECTED] wrote: One issue that seems evident now is that if we store styled text in a field and need to save that to a custom prop, there's 1) loss of data possible (the rev-html converter - or rather stripper), 2) the overhead of saving extra style tags... True. If you need to store styled text it's hard to beat the performance and storage efficiencies of the native binary style runs (i.e. field objects). -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: # POSSIBLY SPAM #::Re: why are custom properties so fast?
On 17.05.2005 09:35:29 use-revolution-bounces wrote: [EMAIL PROTECTED] wrote: One issue that seems evident now is that if we store styled text in a field and need to save that to a custom prop, there's 1) loss of data possible (the rev-html converter - or rather stripper), 2) the overhead of saving extra style tags... True. If you need to store styled text it's hard to beat the performance and storage efficiencies of the native binary style runs (i.e. field objects). Very interesting in terms of TAOO's objects - these are based on cards or records if you prefer... Accessing them quickly has always been a goal in terms of TAOO's information at your fingertip... Now that im approaching networking, this is quite a twist to consider if there is any performance lag... Thanks for the insights! cheers Xavier - Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast? RAM?
--- Richard Gaskin [EMAIL PROTECTED] wrote: When a stack is opened, the whole thing is in RAM, field properties and all. The difference is the overhead associated with each storage mechanism: While fields appear to us to be simple to work with, that's all smoke and mirrors -- under the hood the engine's doing a lot of work setting up storage for style runs, calulating visual line breaks, interacting with the OS font routines, etc. In contrast, all a property does is hold the data. thanks, this explains it. Erik Hansen [EMAIL PROTECTED]http://www.erikhansen.org __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
--- Richard Gaskin [EMAIL PROTECTED] wrote: Howdy Eric - Compared to a field nearly anything else will be faster because of the overhead associated with all the other things fields have to do to display text in addition to storing it. ... For the benefit of anyone who's never had to deal with the tedium of low-level languages, you can visualize what's happening by imagining needing to alter the contents of two buckets: 1. PROPERTY: This bucket is on the floor right in front of you. 2. FIELD: This bucket is down the hall... it sounds like a custom property is a kind of global. where are they stored? where do they go when the glimmies are neemer? guess i'll have to kilackety to Monterey to deek harp the kimmies brightlighters. Erik Hansen [EMAIL PROTECTED]http://www.erikhansen.org Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
Erik Hansen wrote: --- Richard Gaskin [EMAIL PROTECTED] wrote: Compared to a field nearly anything else will be faster because of the overhead associated with all the other things fields have to do to display text in addition to storing it. ... For the benefit of anyone who's never had to deal with the tedium of low-level languages, you can visualize what's happening by imagining needing to alter the contents of two buckets: 1. PROPERTY: This bucket is on the floor right in front of you. 2. FIELD: This bucket is down the hall... it sounds like a custom property is a kind of global. In terms of speed, darn close. where are they stored? In the stack file, in a way that's much easier to get to than field contents. where do they go when the glimmies are neemer? They can be saved with the file. So they have two distinctions from globals: they're bound to an object, and they can be persistent between sessions. guess i'll have to kilackety to Monterey to deek harp the kimmies brightlighters. Demoshed? Kilackety is bahlest anyway, and only a few belhoons. I'm pikin' from the brightlights kilackety myself. It'll be a mighty fine tidrik, deekin' on the typin' moches, harpin' lews and larmers, otin' the greymatter, hootin', and hornin' frattey and gormin' swimmies like an ab-chaser. I'll shy the nonch harpins so there'll be nee haines-crispin (I'll be plenty slugged so I won't be as ose-draggy neemer), and it'll be tidrick aplenty with all the kimmies and minks. Will the squirrel bacon be there? It'd be good to harp the bloochins with him. Ain't deeked Cozens in plenty teem. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
On 5/14/05 4:48 PM, Erik Hansen [EMAIL PROTECTED] wrote: --- Richard Gaskin [EMAIL PROTECTED] wrote: Howdy Eric - Compared to a field nearly anything else will be faster because of the overhead associated with all the other things 2. FIELD: This bucket is down the hall... it sounds like a custom property is a kind of global. where are they stored? where do they go when the glimmies are neemer? They shy and shotgun, 'course. :-) Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
--- Richard Gaskin [EMAIL PROTECTED] wrote: where are they stored? In the stack file, in a way that's much easier to get to than field contents. where do they go when the glimmies are neemer? They can be saved with the file. So they have two distinctions from globals: they're bound to an object, and they can be persistent between sessions. so the stack file is in memory, then stored on disk between sessions? guess i'll have to kilackety to Monterey to deek harp the kimmies brightlighters. Demoshed? Kilackety is bahlest anyway, and only a few belhoons. I'm pikin' from the brightlights kilackety myself. It'll be a mighty fine tidrik, deekin' on the typin' moches, harpin' lews and larmers, otin' the greymatter, hootin', and hornin' frattey and gormin' swimmies like an ab-chaser. I'll shy the nonch harpins so there'll be nee haines-crispin (I'll be plenty slugged so I won't be as ose-draggy neemer), and it'll be tidrick aplenty with all the kimmies and minks. Will the squirrel bacon be there? It'd be good to harp the bloochins with him. Ain't deeked Cozens in plenty teem. yep. [EMAIL PROTECTED]http://www.erikhansen.org __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: why are custom properties so fast?
Howdy Eric - Erik Hansen wrote: --- Richard Gaskin [EMAIL PROTECTED] wrote: The inventor of the engine, Scott Raney, once recommended to me to use stacks with only about 5,000 cards, and if you need more you'll get better performance using a database like Valentina for storage and retrieval. But Dr. Raney overlooked the beauty and simplicity of his own custom properties. I've worked on projects with tens of thousands of custom properties with narry a blink. why are custom properties so fast? Compared to a field nearly anything else will be faster because of the overhead associated with all the other things fields have to do to display text in addition to storing it. I wrote this a while back in response to a related question: To get data in and out of a field, given the various style run mechanisms and other special considerations, the process is a lot more work under the hood than using a custom property. For the benefit of anyone who's never had to deal with the tedium of low-level languages, you can visualize what's happening by imagining needing to alter the contents of two buckets: 1. PROPERTY: This bucket is on the floor right in front of you. 2. FIELD: This bucket is in a room down the hall and around the corner, turn left, then go through the first door, turn right, go through the double-doors, then take the hall on the left to the staircase, go downstairs, and on your right you'll find a storage bin -- the bucket is in the bin, behind a mop. Before you can pick up the bucket you'll need to move the mop, but the mop is wet so you'll need to put some rags on the floor in front of you to catch the moisture so it doesn't make the floor unsafe. You'll find some rags in the next room through the door on the right, inside a metal box. Be sure to put the lid back on the box after retrieving the rags so you don't let mice nest there. Back in the storage room spread the rags out sufficiently to catch the moisture but not so many that you trip over them, then put the mop on them, and then get the bucket. After changing the bucket's contents you'll want to put it back first, then the mop, then collect all of the rags and put them in the laundry hamper in the room on the left. To make sure the cleaning crew knows to wash the rags you'll need to fill out the laundry request form you'll find on a clipboard hanging on the wall next to the light switch. After it's filled out be sure to turn off the light in the laundry room and the one in the storage room, and then return to where you started. In terms of the number of instructions to access the contents of a property vs. a field, this comparison with buckets is probably missing a few steps in #2. And if there's a scrollbar attached to the field then double the number of steps. :) -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
