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
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
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
[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
--- 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
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
[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
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.
[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
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
--- 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
--- 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
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
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
--- 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
--- Ken Ray [EMAIL PROTECTED] wrote:
where do they go when the glimmies are
neemer?
They shy and shotgun, 'course.
OK.
thanks to:
Boontling An American Lingo
Charles C. Adams
UT Press, Austin
great photos.
formation of a new lingo may not be so
completely OT after all.
still needed:
are custom properties so fast?
Erik Hansen
[EMAIL PROTECTED]http://www.erikhansen.org
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
use
.
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
18 matches
Mail list logo
