Peter Haworth wrote:
I have to admit you guys left me behind a while ago. But I'm glad I
may have created a platform for some knowledge that wasn't there
before, plus I've got a fix for my problem so yes, definitely a good
day!
Thanks again for not only bringing this up, but for diligently
No problem Richard, fun tracking this stuff down. After your last
email, I now understand the exact reason for the slowdown.
I now plan to switch all my long name references over to use the
control ID. Everything in the doc says using the ID should be a safe
way to uniquely identify a
On 11/12/10 11:44 AM, Peter Haworth wrote:
There's a little trepidation on my part about
that because I occasionally see posts that suggest that maybe there's
issues with the uniqueness of IDs but hopefully I won;t run into them!
They won't change unless you change them yourself, and the only
Yay! Nice catch. You had me going there for a while. I wonder though how this
would affect a standalone which uses sqlYoga? As I mentioned, sqlYoga uses the
long ID of the button object that stores the database objects as properties.
Seems to me however that it might be better to just let the
Figured out the IDE/Standalone performance issue, it's nothing to do
with the code.
I my last email I mentioned how I have a custom property holding the
long names of all the controls on a card that need to have data loaded
into them from my database. On closer inspection, the long name
Peter Haworth wrote:
Figured out the IDE/Standalone performance issue, it's nothing to do
with the code.
I my last email I mentioned how I have a custom property holding the
long names of all the controls on a card that need to have data loaded
into them from my database. On closer
Unless you're explicitly purging the stacks, any access to a property of a
stack file will load it into memory. The first access will take a hit only
if the stack isn't already in memory, but subsequent accesses should be about
as fast whether referring to just the stack name or the stack
Yes, that's what I'm seeing. With the references to my .rev filepath
in the control names, the card I'm using to test was taking around 35
seconds to open. I went through and manually removed the references
to the filepath (that's the only thing I changed I swear!) and built
the
Monte Goulding wrote:
Unless you're explicitly purging the stacks, any access to
a property of a stack file will load it into memory. The
first access will take a hit only if the stack isn't already
in memory, but subsequent accesses should be about as fast
whether referring to just the
Unless you're explicitly purging the stacks, any access to
a property of a stack file will load it into memory. The
first access will take a hit only if the stack isn't already
in memory, but subsequent accesses should be about as fast
whether referring to just the stack name or the
I guess my experience suggests strongly that the stack doesn't stay in memory
but I can't prove it. Is there something I can write to my debug log that would
help prove this one way or the other?
Richard Gaskin ambassa...@fourthworld.com wrote:
Monte Goulding wrote:
Unless you're explicitly
Monte Goulding wrote:
I never said it wasn't loaded into memory. I know it is and it
didn't make sense to me at the time that there would be such a
performance difference. Maybe it was something to do with
resolving the filename? I'm not sure, I just know it was slower.
There's probably
There's probably some nuance I'm missing - here's a quick test which first
uses the fileName of a stack to access a property, then the next run it opens
the stack and gets the property by referring to the stack's short name (FWIW,
I had saved the stack previously with its destroyStack set
Monte Goulding wrote:
I ran a quick test with a stack with 500 graphics and a slightly
different script:
on mouseUp
put fld file into tStackFile
--
delete stack tStackFile
put the millisecs into t
repeat with X=1 to the number of grcs of stack tStackFile
put
I have to admit you guys left me behind a while ago. But I'm glad I
may have created a platform for some knowledge that wasn't there
before, plus I've got a fix for my problem so yes, definitely a good
day!
Pete Haworth
On Nov 11, 2010, at 7:04 PM, Richard Gaskin wrote:
Great work,
15 matches
Mail list logo
