subject:"Performance"

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, Monte!  Thanks for running that test.

So the difference is in addressing controls *within* a stack, but  
not with the stack itself.  Hard to anticipate, but very good to know.


So Peter has a solution, and I learned two new things today about  
performance.


A good day...


___
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: Performance Mystery Solved - IT'S THE DATA STUPID!!


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 the uTest of grc X of stack tStackFile into r1
> end repeat
> put the millisecs - t into t1
> --
> delete stack tStackFile
>put the millisecs into t
> toplevel tStackFile
> put the short name of stack tStackFile into tStack
> repeat with X=1 to the number of grcs of stack tStack
>  put the uTest of grc X of stack tStack into r2
> end repeat
> close stack tStackFile
> put the millisecs - t into t2
> --
> put t1 && t2 &&(r1=r2) into fld "r"
> end mouseUp
>
> Result: 1034 212 true
>
> There was no significant difference with destroyStack property true
> or false. Adding another 500 graphics to the card resulted in this:
> 8863 399 true
>
> Changing toplevel to go invisible stack resulted in this:
> 8596 72 true

Great work, Monte!  Thanks for running that test.

So the difference is in addressing controls *within* a stack, but not 
with the stack itself.  Hard to anticipate, but very good to know.


So Peter has a solution, and I learned two new things today about 
performance.


A good day...

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.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: Performance Mystery Solved - IT'S THE DATA STUPID!!

2010-11-11 Thread Monte Goulding

> 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 to true to try to 
> maximize any load difference):
> 
> 
> on mouseUp
>  put 1 into n
>  put fld "file" into tStackFile
>  --
>  put the millisecs into t
>  repeat n
>put the uTest of stack tStackFile into r1
>  end repeat
>  put the millisecs - t into t1
>  --
>  put the millisecs into t
>  toplevel tStackFile
>  put the short name of stack tStackFile into tStack
>  repeat n
>put the uTest of stack tStack into r2
>  end repeat
>  close stack tStackFile
>  put the millisecs - t into t2
>  --
>  put t1 && t2 &&(r1=r2) into fld "r"
> end mouseUp
> 
> Result:  151 140 true
> 
> The difference is small even across 10,000 iterations, and can be explained 
> by the need to resolve the path to a stack reference.
> 
> How can this test be modified to show a greater difference?

Good question. It was iterating over the controls in a stack so I'm not sure if 
that would make any difference. I believe the user had something like 2 
graphics on a card. I can't remember if the destroyStack was true or not. 

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 the uTest of grc X of stack tStackFile into r1
end repeat
put the millisecs - t into t1
--
delete stack tStackFile
   put the millisecs into t
toplevel tStackFile
put the short name of stack tStackFile into tStack
repeat with X=1 to the number of grcs of stack tStack
 put the uTest of grc X of stack tStack into r2
end repeat
close stack tStackFile
put the millisecs - t into t2
--
put t1 && t2 &&(r1=r2) into fld "r"
end mouseUp

Result: 1034 212 true

There was no significant difference with destroyStack property true or false. 
Adding another 500 graphics to the card resulted in this:
8863 399 true

Changing toplevel to go invisible stack resulted in this:
8596 72 true

Cheers

Monte___
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: Performance Mystery Solved - IT'S THE DATA STUPID!!


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 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 to true to try to maximize any load difference):



on mouseUp
  put 1 into n
  put fld "file" into tStackFile
  --
  put the millisecs into t
  repeat n
put the uTest of stack tStackFile into r1
  end repeat
  put the millisecs - t into t1
  --
  put the millisecs into t
  toplevel tStackFile
  put the short name of stack tStackFile into tStack
  repeat n
put the uTest of stack tStack into r2
  end repeat
  close stack tStackFile
  put the millisecs - t into t2
  --
  put t1 && t2 &&(r1=r2) into fld "r"
end mouseUp

Result:  151 140 true

The difference is small even across 10,000 iterations, and can be 
explained by the need to resolve the path to a stack reference.


How can this test be modified to show a greater difference?

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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: Performance Mystery Solved - IT'S THE DATA STUPID!!

2010-11-11 Thread Pete Haworth

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"  wrote:

>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 stack name or the stack file
> >> path, since they're interchangeable for mainstacks.
> >
> > I don't think this is entirely true. At least it wasn't when
> > I was working on the standalone builder all those years ago.
> > There was a massive difference in speed between looping over
> > the controls of a stack if that stack was invisible toplevel
> > compared to just referencing it as a filename. There was a
> > user that was having extremely slow builds because they had
> > so many controls.
>
>It would make me very happy if that were the case.
>
>A couple years ago there was a long thread here in which I complained 
>that if I access a property in a stack but don't explicitly open the 
>stack, IMO the behavior should be as it was in SuperCard:  the stack 
>file is read into memory to obtain the property value, and then the
>copy 
>in memory is disposed of.
>
>What was happening instead is that the stack file was hanging out in 
>memory just the same as if I had opened it, and many here argued that 
>that was a good thing.
>
>I haven't tested this myself in a long time - got any current
>benchmarks?
>
>If the behavior has changed then Trevor, Chipp, Jacque, and a good many
>
>others who voiced an opinion that leaving it in memory was valuable may
>
>not like it, but I'll be quite happy indeed. :)
>
>--
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>  LiveCode Journal blog: http://LiveCodejournal.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


Pete Haworth
Molly's Revenge
www.mollysrevenge.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: Performance Mystery Solved - IT'S THE DATA STUPID!!

2010-11-11 Thread Monte Goulding

> >> 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 file
> >> path, since they're interchangeable for mainstacks.
> >
> > I don't think this is entirely true. At least it wasn't when
> > I was working on the standalone builder all those years ago.
> > There was a massive difference in speed between looping over
> > the controls of a stack if that stack was invisible toplevel
> > compared to just referencing it as a filename. There was a
> > user that was having extremely slow builds because they had
> > so many controls.
> 
> It would make me very happy if that were the case.
> 
> A couple years ago there was a long thread here in which I complained that if 
> I access a property in a stack but don't explicitly open the stack, IMO the 
> behavior should be as it was in SuperCard:  the stack file is read into 
> memory to obtain the property value, and then the copy in memory is disposed 
> of.

Well even better would be an index at the start of the stack file so the whole 
file wasn't read into memory, just the prop value. I'd like this to be an 
option though rather than normal behavior. 
> 
> What was happening instead is that the stack file was hanging out in memory 
> just the same as if I had opened it, and many here argued that that was a 
> good thing.
> 
> I haven't tested this myself in a long time - got any current benchmarks?

No, like I said this is just what I remember from when we were in beta with the 
standalone builder and it was a fair while ago now. It shouldn't be that hard 
to put together a benchmark test stack though.
> 
> If the behavior has changed then Trevor, Chipp, Jacque, and a good many 
> others who voiced an opinion that leaving it in memory was valuable may not 
> like it, but I'll be quite happy indeed. :)

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.

Cheers

Monte___
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: Performance Mystery Solved - IT'S THE DATA STUPID!!

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 stack name or the stack file
>> path, since they're interchangeable for mainstacks.
>
> I don't think this is entirely true. At least it wasn't when
> I was working on the standalone builder all those years ago.
> There was a massive difference in speed between looping over
> the controls of a stack if that stack was invisible toplevel
> compared to just referencing it as a filename. There was a
> user that was having extremely slow builds because they had
> so many controls.

It would make me very happy if that were the case.

A couple years ago there was a long thread here in which I complained 
that if I access a property in a stack but don't explicitly open the 
stack, IMO the behavior should be as it was in SuperCard:  the stack 
file is read into memory to obtain the property value, and then the copy 
in memory is disposed of.

What was happening instead is that the stack file was hanging out in 
memory just the same as if I had opened it, and many here argued that 
that was a good thing.

I haven't tested this myself in a long time - got any current benchmarks?

If the behavior has changed then Trevor, Chipp, Jacque, and a good many 
others who voiced an opinion that leaving it in memory was valuable may 
not like it, but I'll be quite happy indeed. :)

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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: Performance Mystery Solved - IT'S THE DATA STUPID!!

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 standalone again and now the card opens just about  
instantaneously.  So maybe there's a bug after all in that the .rev  
stack should only be loaded into memory at the first access to it but  
it's happening every time?


Whatever the issue, I have to change something because my standalone  
wouldn't run unless the .rev file was on the same computer and that  
doesn't make any sense.  I think I'm going to bite the bullet and  
change everything over to use control IDs instead of long names.


Pete Haworth

On Nov 11, 2010, at 5:12 PM, 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 stack name or the stack file path, since they're  
interchangeable for mainstacks.


Hi Richard

I don't think this is entirely true. At least it wasn't when I was  
working on the standalone builder all those years ago. There was a  
massive difference in speed between looping over the controls of a  
stack if that stack was invisible toplevel compared to just  
referencing it as a filename. There was a user that was having  
extremely slow builds because they had so many controls.


Cheers

Monte___
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: Performance Mystery Solved - IT'S THE DATA STUPID!!

2010-11-11 Thread Monte Goulding

> 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 file path, 
> since they're interchangeable for mainstacks.

Hi Richard

I don't think this is entirely true. At least it wasn't when I was working on 
the standalone builder all those years ago. There was a massive difference in 
speed between looping over the controls of a stack if that stack was invisible 
toplevel compared to just referencing it as a filename. There was a user that 
was having extremely slow builds because they had so many controls.

Cheers

Monte___
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: Performance Mystery Solved - IT'S THE DATA STUPID!!


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 inspection, the long name
includes the name of the stack file which - duh - is my .rev file!!!
So when the standalone gets the long name of a control from the custom
property, it is referencing the control in my.rev file, not the
control in the standalone, and presumably has to go open the .rev file
every time my code refers to a control.  No wonder everything took
longer.  Using the ID removes that problem of course.


Bad news:  I don't think that's the problem.

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 file path, since they're interchangeable for mainstacks.


Moreover, if the data stored in the standalone is subject to change, 
you'll want to migrate that to a separate stack file anyway since the OS 
doesn't allow executables to modify themselves.


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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

Performance Mystery Solved - IT'S THE DATA STUPID!!

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  
includes the name of the stack file which - duh - is my .rev file!!!   
So when the standalone gets the long name of a control from the custom  
property, it is referencing the control in my.rev file, not the  
control in the standalone, and presumably has to go open the .rev file  
every time my code refers to a control.  No wonder everything took  
longer.  Using the ID removes that problem of course.


I still have to figure out what to about this.  I can either change my  
code to use the ID everywhere instead of the long name, or I can  
somehow parse out the the part of the long name that is the path to  
my .rev file.  Or I could build the list of controls in the standalone  
(currently it specifically doesn't do that on the grounds that it  
didn't need to).


Sorry for the false alarms!

Pete Haworth








___
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: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!


See answers below.

Pete Haworth



What's interesting there is that the control is only being  
referenced three times:  once to write the debug string, a second  
time to check the customKeys, and a third time to obtain the prop  
values.


Given that it's just three object references and most of the work is  
done in the repeat look that works on the list, it's hard to believe  
those three object references could account for the speed difference  
by themselves.


What does writeDebug look like, and what does the other half of the  
repeat look like (there's no closing "end repeat")?


Here's writeDebug and another function it calls getprefsFolderPath.

command writeDebug pText
   put getprefsFolderPath("BandTrak") & "debuglog.txt" into  
myPrefsFilePath

   write pText & return to file myPrefsFilePath
end writeDebug

function getPrefsFolderPath pSubFolder
   if the environment is "development" then
  put the effective filename of this stack into prefsFolder
  set the itemdelimiter to slash
  put item 1 to -2 of prefsFolder into prefsFolder
   else
  if the platform = "MacOS" then
 put specialFolderPath("Preferences") into prefsFolder
  else if the platform = "Win32" then
 put specialFolderPath(26) into prefsFolder
  end if
   end if
   if last char of prefsFolder is not "/" then
  put slash after prefsFolder
   end if
   if the environment is not "development" then
  put pSubFolder & slash after prefsFolder
   end if
   return prefsFolder
end getPrefsFolderPath

I didn't put the rest of the repeat lop in the example because the  
timing ends at the top of the repeat loop.  I can give you the code  
but it's basically executing an SQLite SELECT statement.  There's  
another time measurement at the completion of the SELECT and it  
indicates there's no significant difference between the IDE and the  
standalone for the SELECT execution.





And what exactly is in myID?  Have you verified that it's an  
integer, and that the name was as you expected it in the earlier  
version?


A little background for you.  This code is part of a library routine I  
have to load values from an SQLite SELECT statement into controls on  
the form.  All the controls on the form that relate to columns in the  
selected row start with DB_ followed by the name of the column.  In  
the IDE, whenever a card is opened, I create a list of the DB_  
controls and store them in a custom property named fieldList, one per  
line.  I'm currently storing the long name of each control in  
fieldList and I can see that they are in the correct format in the  
custom property.  There's an outer loop that processes every line in  
fieldList to load the data into the controls and to help track this  
down, I put the following statement in that loop:


put the ID of myControl into myID

myControl is the variable that holds one line from the fieldList  
custom property.  I guess that's a long winded way of saying yes, the  
long name formats look correct.  I haven't checked myID to see if it  
holds an integer but unless the put statement is doing something  
weird, I'm pretty sure it does.




Also, do you have any getProp handlers in your stack?


I do have some getProp and setProp handlers but not for the properties  
used in this section of code.  I had wondered if there was something  
of that nature happening, so I stepped through every line of code in  
debug to make sure it wasn't dashing off into some hidden direction  
like that and I didn;t see anything of that nature.


Perhaps most importantly:  are there any other stacks or libraries  
used by the standalone that aren't present in the IDE?


I don;t think so, certainly not intentionally,but I'm not sure how to  
tell.  I used the Stacks tab of the Standalone Application Settings to  
set the stacks other than the main application stack that were to be  
included in the standalone.






It is puzzling why your tests don't reflect what Im experiencing.


Yeah, me too. :)


Maybe it's something to do with the operation that is carried out on
the control.  In my case, most of the addressing of the controls
consists of getting/setting their properties, both standard and
custom.  Could it have anything to do with the fact that my code is
executed in a script that is held in a separate code library stack  
and

inserted as a front script?


Possibly. It may be helpful to log the frontScripts, the  
backScripts, and the stacksInUse in both the IDE and the standalone  
to see what differences there may be.  Of course you'll see a lot  
more of those in the IDE, which should theoretically either have no  
effect or make it slower, but perhaps a script is both in a library  
and a frontScript in the standalone, causing it to execute more than  
once.


OK I did that.  Here's the output from the IDE"

FrontScripts
card id 1004 of stack "/Users/Dad/RevDev/Code Library.rev"
card id 1003 of stack "/Users/Dad/RevDev/Code Library.rev"
card id 100

Re: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!


Peter Haworth wrote:


Here's a small example section of code which I've changed to use the
ID where it used to use the long name.  The variables are:

myIDholds the short ID of the control
pselection  a parameter passed into the command

put the milliseconds into mymilliseconds
writeDebug "Starting loadOneList"  && the abbrev name of control ID myID
if pselection is empty then
   if "listValues" is among the lines of the customKeys of control
ID myID then
  put the listValues of control ID myID into tlistspec
   else
  put the text of control ID myID into tdata
   end if
else
   put pselection into tlistspec
end if
if tlistspec is not empty then
   repeat for each line myLine in tlistspec
   writeDebug tab & (the milliseconds - mymilliseconds) & tab &
"Start processing SELECT"  && myline


What's interesting there is that the control is only being referenced 
three times:  once to write the debug string, a second time to check the 
customKeys, and a third time to obtain the prop values.


Given that it's just three object references and most of the work is 
done in the repeat look that works on the list, it's hard to believe 
those three object references could account for the speed difference by 
themselves.


What does writeDebug look like, and what does the other half of the 
repeat look like (there's no closing "end repeat")?


And what exactly is in myID?  Have you verified that it's an integer, 
and that the name was as you expected it in the earlier version?


Also, do you have any getProp handlers in your stack?

Perhaps most importantly:  are there any other stacks or libraries used 
by the standalone that aren't present in the IDE?




It is puzzling why your tests don't reflect what Im experiencing.


Yeah, me too. :)


Maybe it's something to do with the operation that is carried out on
the control.  In my case, most of the addressing of the controls
consists of getting/setting their properties, both standard and
custom.  Could it have anything to do with the fact that my code is
executed in a script that is held in a separate code library stack and
inserted as a front script?


Possibly. It may be helpful to log the frontScripts, the backScripts, 
and the stacksInUse in both the IDE and the standalone to see what 
differences there may be.  Of course you'll see a lot more of those in 
the IDE, which should theoretically either have no effect or make it 
slower, but perhaps a script is both in a library and a frontScript in 
the standalone, causing it to execute more than once.


getProp and setProp handlers can be mystifyingly problematic because I 
find that the more of those there are the more all custom property 
accesses slow down (though the effect is very minor, a fraction of a 
microsecond).



The only other variable I can think of is
the location of the debug log I'm writing to.  In the IDE, the debug
log is in the same folder as the stack file but in the standalone it's
in the users Library/Preferences/ folder.  This is running on
a Mac of course.


That's a noteworthy point.  When diagnosing issues like this it's very 
useful to eliminate differences between the working and non-working 
implementations until you hone in on the root cause.


To verify that this isn't an issue with writing to a different location, 
you might consider altering the standalone (at least temporarily, for 
this test) so that it writes to the same location as when it's run in 
the IDE.




All I have to do now is find all the places in my code where controls
are referenced by their long name - oh joy!


Hopefully we'll be able to find a different root cause than the current 
apparent one, maybe one that requires less work to remedy. :)


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!


Thanks for delving into this Richard.

Here's a small example section of code which I've changed to use the  
ID where it used to use the long name.  The variables are:


myIDholds the short ID of the control
pselection  a parameter passed into the command

put the milliseconds into mymilliseconds
writeDebug "Starting loadOneList"  && the abbrev name of control ID myID
if pselection is empty then
  if "listValues" is among the lines of the customKeys of control  
ID myID then

 put the listValues of control ID myID into tlistspec
  else
 put the text of control ID myID into tdata
  end if
   else
  put pselection into tlistspec
   end if
   if tlistspec is not empty then
  repeat for each line myLine in tlistspec
  writeDebug tab & (the milliseconds - mymilliseconds) & tab &  
"Start processing SELECT"  && myline


In the IDE, the 2nd writeDebug shows a value of 1 whether I use the  
long name or the ID of the control.  In the standalone, using the long  
name it shows a value of 731 and using the ID it shows 1 again.


It is puzzling why your tests don't reflect what Im experiencing.  
Maybe it's something to do with the operation that is carried out on  
the control.  In my case, most of the addressing of the controls  
consists of getting/setting their properties, both standard and  
custom.  Could it have anything to do with the fact that my code is  
executed in a script that is held in a separate code library stack and  
inserted as a front script?  The only other variable I can think of is  
the location of the debug log I'm writing to.  In the IDE, the debug  
log is in the same folder as the stack file but in the standalone it's  
in the users Library/Preferences/ folder.  This is running on  
a Mac of course.


All I have to do now is find all the places in my code where controls  
are referenced by their long name - oh joy!


Bob - I want to hold off just a little longer before submitting a  
bug.  The fact that Richard's tests don;t reflect what I'm seeing make  
me nervous that it's something I'm doing wrong!


Pete

On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:



Interesting.  I just ran this test:

on mouseUp
 put 10 into n
 --
 put the millisecs into t
 repeat n
   put the short id of this cd into tID
   put the name of cd id tID into r1
 end repeat
 put the millisecs - t into t1
 --
 put the millisecs into t
 repeat n
   put the long name of this cd into tName
   put the name of tName into r2
 end repeat
 put the millisecs - t into t2
 --
 put the millisecs into t
 repeat n
   put the number of this cd into tNum
   put the name of cd tNum into r3
 end repeat
 put the millisecs - t into t3
 --
 put t1 && t2 && t3 && (r1=r3)
end mouseUp


The results were roughly the same in both the MC and Rev IDEs:

221 954 209 true

So addressing by ordinal number is slightly faster than by ID, which  
has been the case since the HC days.  But I'm surprised by how much  
faster both are compared to addressing by name.


This got me curious as to whether long ID would be faster than long  
name, so I ran this:


on mouseUp
 put 10 into n
 --
 put the millisecs into t
 repeat n
   put the long id of this cd into tID
   put the name of tID into r1
 end repeat
 put the millisecs - t into t1
 --
 put the millisecs into t
 repeat n
   put the long name of this cd into tName
   put the name of tName into r2
 end repeat
 put the millisecs - t into t2
 --
 put t1 && t2 && (r1=r2)
end mouseUp


...and got this:

955 957 true

So it seems that the overhead of resolving absolute object  
references (long form) is much higher than what the engine can do  
when you're able to hard-wire part of the reference (e.g., "...of  
card id tID...").


Historically I've often used long IDs for the convenience of having  
an absolute object reference without regard to the type, but after  
seeing these results I can see that there's a benefit to hard-wire  
the type in script where practical.


Thanks for bringing this up.  Learn sumpin' new every day. :)



Finding the problem is good of course but does anyone know why there
are no performance issues referring to an object by it's long name in
the IDE but it causes such a performance hit in a standalone?


Interesting as it was to test the different ways to reference  
objects, in practical terms I think the performance issue you  
encountered is due to something else.


The tests shown above were run in 100,000 iterations.  So while it  
seems impressive that one took only 25% as much time as another, in  
a given iteration the longest one took only 0.00954 ms.


Unless you're addressing several hundred thousand objects at a time,  
it's hard to imagine how the difference could product a noticeable  
effect.


I even b

Re: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!


Bob Sneidar wrote:

> On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:
>
>> So it seems that the overhead of resolving absolute object
>> references (long form) is much higher than what the engine
>> can do when you're able to hard-wire part of the reference
>> (e.g., "...of card id tID...").
>>
>> Historically I've often used long IDs for the convenience
>> of having an absolute object reference without regard to
>> the type, but after seeing these results I can see that
>> there's a benefit to hard-wire the type in script where practical.
>>
>> Thanks for bringing this up.  Learn sumpin' new every day. :)
>
> Yeah, and Peter's issue was that with standalones, the problem is
> many orders of magnitude worse.

Understood, but as I noted I was unable to measure any difference 
between standalone and IDE performance greater than about 0.0008 ms per 
call.


At that rate it would take many hundreds of thousands of object 
references to see a difference.


<http://mail.runrev.com/pipermail/use-revolution/2010-November/148105.html>

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!

2010-11-11 Thread Bob Sneidar

Yeah, and Peter's issue was that with standalones, the problem is many orders 
of magnitude worse. 

Bob


On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:

> So it seems that the overhead of resolving absolute object references (long 
> form) is much higher than what the engine can do when you're able to 
> hard-wire part of the reference (e.g., "...of card id tID...").
> 
> Historically I've often used long IDs for the convenience of having an 
> absolute object reference without regard to the type, but after seeing these 
> results I can see that there's a benefit to hard-wire the type in script 
> where practical.
> 
> Thanks for bringing this up.  Learn sumpin' new every day. :)

___
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: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!


Peter Haworth wrote:


I think I have found  the cause of the performance problems I have
been experiencing.  I had been referring to objects by their long name
in various places in the offending code.  I started changing the code
to refer to the same objects by their short ID and each line of code I
changed resulted in quicker performance.  I haven't been able to
change all the code yet but the evidence is that the performance
issues will go away when I start using the object IDs everywhere.


Interesting.  I just ran this test:

on mouseUp
  put 10 into n
  --
  put the millisecs into t
  repeat n
put the short id of this cd into tID
put the name of cd id tID into r1
  end repeat
  put the millisecs - t into t1
  --
  put the millisecs into t
  repeat n
put the long name of this cd into tName
put the name of tName into r2
  end repeat
  put the millisecs - t into t2
  --
  put the millisecs into t
  repeat n
put the number of this cd into tNum
put the name of cd tNum into r3
  end repeat
  put the millisecs - t into t3
  --
  put t1 && t2 && t3 && (r1=r3)
end mouseUp


The results were roughly the same in both the MC and Rev IDEs:

221 954 209 true

So addressing by ordinal number is slightly faster than by ID, which has 
been the case since the HC days.  But I'm surprised by how much faster 
both are compared to addressing by name.


This got me curious as to whether long ID would be faster than long 
name, so I ran this:


on mouseUp
  put 10 into n
  --
  put the millisecs into t
  repeat n
put the long id of this cd into tID
put the name of tID into r1
  end repeat
  put the millisecs - t into t1
  --
  put the millisecs into t
  repeat n
put the long name of this cd into tName
put the name of tName into r2
  end repeat
  put the millisecs - t into t2
  --
  put t1 && t2 && (r1=r2)
end mouseUp


...and got this:

955 957 true

So it seems that the overhead of resolving absolute object references 
(long form) is much higher than what the engine can do when you're able 
to hard-wire part of the reference (e.g., "...of card id tID...").


Historically I've often used long IDs for the convenience of having an 
absolute object reference without regard to the type, but after seeing 
these results I can see that there's a benefit to hard-wire the type in 
script where practical.


Thanks for bringing this up.  Learn sumpin' new every day. :)



Finding the problem is good of course but does anyone know why there
are no performance issues referring to an object by it's long name in
the IDE but it causes such a performance hit in a standalone?


Interesting as it was to test the different ways to reference objects, 
in practical terms I think the performance issue you encountered is due 
to something else.


The tests shown above were run in 100,000 iterations.  So while it seems 
impressive that one took only 25% as much time as another, in a given 
iteration the longest one took only 0.00954 ms.


Unless you're addressing several hundred thousand objects at a time, 
it's hard to imagine how the difference could product a noticeable effect.


I even built a standalone of the test stack, and while it was somewhat 
slower (why would that be?) the difference between the IDE and the 
standalone was less than 8% total, or about 0.0008 ms per call.


This is disappointing because it leaves the mystery unresolved, unless I 
misunderstand something here.


Can you post the section of code in question so we can see what else 
might be at play?


Also, have you compared timing tests of an isolated portion of the code 
to hone in on where the performance is lost?


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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: IDE/Standalone Performance Issues - A Light At The End of the Tunnel!

2010-11-11 Thread Bob Sneidar

Again, Peter, I think you have hit on something here. Good detective work. So 
it was not the SQL queries that were causing the delay? Good to know. I think 
it is a bug of some kind, but then I am the Bugmeister, so that is expected. 

I would submit a bug and see where it goes. 

Bob


On Nov 11, 2010, at 10:03 AM, Peter Haworth wrote:

> I think I have found  the cause of the performance problems I have been 
> experiencing.  I had been referring to objects by their long name in various 
> places in the offending code.  I started changing the code to refer to the 
> same objects by their short ID and each line of code I changed resulted in 
> quicker performance.  I haven't been able to change all the code yet but the 
> evidence is that the performance issues will go away when I start using the 
> object IDs everywhere.
> 
> Finding the problem is good of course but does anyone know why there are no 
> performance issues referring to an object by it's long name in the IDE but it 
> causes such a performance hit in a standalone?  Maybe I'm misunderstanding 
> the process of building a standalone but I would have thought a standalone 
> would function more efficiently than the same code executed in the IDE not 
> less, kinda like in the old days of interpretive vs compiled BASIC?
> 
> Pete Haworth
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

IDE/Standalone Performance Issues - A Light At The End of the Tunnel!

I think I have found  the cause of the performance problems I have  
been experiencing.  I had been referring to objects by their long name  
in various places in the offending code.  I started changing the code  
to refer to the same objects by their short ID and each line of code I  
changed resulted in quicker performance.  I haven't been able to  
change all the code yet but the evidence is that the performance  
issues will go away when I start using the object IDs everywhere.


Finding the problem is good of course but does anyone know why there  
are no performance issues referring to an object by it's long name in  
the IDE but it causes such a performance hit in a standalone?  Maybe  
I'm misunderstanding the process of building a standalone but I would  
have thought a standalone would function more efficiently than the  
same code executed in the IDE not less, kinda like in the old days of  
interpretive vs compiled BASIC?


Pete Haworth








___
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: More on IDE vs Standalone Performance issues

2010-11-09 Thread Peter Haworth

Right now, it's all part of a pretty large application but I think I  
can create a simple test stack with one card in it, although you'll  
still need the SQLite database.


I haven't posted stack files before - how do I do that?

Pete Haworth


On Nov 9, 2010, at 12:10 PM, use-revolution-requ...@lists.runrev.com  
wrote:



Date: Tue, 9 Nov 2010 10:26:39 -0800
From: Bob Sneidar 
Subject: Re: More on IDE vs Standalone Performance issues
To: How to use Revolution 
Message-ID: <6f5b0f5e-e1a5-4c49-93af-bca8c73fc...@twft.com>
Content-Type: text/plain; charset=us-ascii

I think you are on to something there Peter. This may be something  
for the bug reports. Is there a test stack with the debug written  
into it that you could post so we can try it on our end?


Bob


___
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: More on IDE vs Standalone Performance issues

2010-11-09 Thread Bob Sneidar

I think you are on to something there Peter. This may be something for the bug 
reports. Is there a test stack with the debug written into it that you could 
post so we can try it on our end? 

Bob


On Nov 9, 2010, at 10:13 AM, Peter Haworth wrote:

> Spent the last day or so trying to get some data to track this problem down 
> by inserting code to write details of the time taken for various chunks of 
> code to execute into a text file so I could see what was going on.  I 
> narrowed it down to a command that loads the text property of an option 
> button by executing an SQLite SELECT statement that is defined in a custom 
> property for the button, then setting the text property of the button to the 
> resulting data.
> 
> I executed the code using exactly the same data in the same database both in 
> the IDE and the standalone.
> 
> Here's a snippet from the debug file relating to the loading of one option 
> button in the IDE:
> 
> Starting loadOneList button "DB_RcvblsAc"
>   0   Start processing SELECT...
>   1   End processing SELECT ...
>   1   Start setting menu text
>   1   End setting menu text
> 
> The number at the start of each line is the number of milliseconds since the 
> start of the loadOneList command.
> 
> Now here is a same snippet taken from the debug file created by the 
> standalone for the same button:
> 
> Starting loadOneList button "DB_RcvblsAc"
>   731 Start processing SELECT...
>   976 End processing SELECT...
>   976 Start setting menu text
>   2196End setting menu text
> 
> As you can see, the time taken between each display is hundreds of times more 
> than in the IDE in every case.  It's not limited to just one snippet of code, 
> it's universal.  Getting through loadOneList takes roughly 1 millisecond in 
> the IDE and more than 2 seconds in the standalone.
> 
> Here's the code that is executed between the "Starting loadOneList" message 
> and the "Start processing SELECT" message:
> 
> if pselection is empty then
>  if "listValues" is among the lines of the customKeys of myControl then
> put the listValues of myControl into tlistspec
>  else
> put the text of myControl into tdata
>  end if
>   else
>  put pselection into tlistspec
>   end if
>   if tlistspec is not empty then
>  repeat for each line myLine in tlistspec
> 
> I stepped through the code in debug to make sure it didn't head off in 
> unexpected directions (eg setProp/getProp handlers) and there was nothing of 
> that nature. The writing of the debug information takes some time but that 
> should be the same overhead in the IDE and the standalone.
> 
> Help!
> 
> Pete Haworth
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

More on IDE vs Standalone Performance issues

2010-11-09 Thread Peter Haworth

Spent the last day or so trying to get some data to track this problem  
down by inserting code to write details of the time taken for various  
chunks of code to execute into a text file so I could see what was  
going on.  I narrowed it down to a command that loads the text  
property of an option button by executing an SQLite SELECT statement  
that is defined in a custom property for the button, then setting the  
text property of the button to the resulting data.


I executed the code using exactly the same data in the same database  
both in the IDE and the standalone.


Here's a snippet from the debug file relating to the loading of one  
option button in the IDE:


Starting loadOneList button "DB_RcvblsAc"
0   Start processing SELECT...
1   End processing SELECT ...
1   Start setting menu text
1   End setting menu text

The number at the start of each line is the number of milliseconds  
since the start of the loadOneList command.


Now here is a same snippet taken from the debug file created by the  
standalone for the same button:


Starting loadOneList button "DB_RcvblsAc"
731 Start processing SELECT...
976 End processing SELECT...
976 Start setting menu text
2196End setting menu text

As you can see, the time taken between each display is hundreds of  
times more than in the IDE in every case.  It's not limited to just  
one snippet of code, it's universal.  Getting through loadOneList  
takes roughly 1 millisecond in the IDE and more than 2 seconds in the  
standalone.


Here's the code that is executed between the "Starting loadOneList"  
message and the "Start processing SELECT" message:


if pselection is empty then
  if "listValues" is among the lines of the customKeys of  
myControl then

 put the listValues of myControl into tlistspec
  else
 put the text of myControl into tdata
  end if
   else
  put pselection into tlistspec
   end if
   if tlistspec is not empty then
  repeat for each line myLine in tlistspec

I stepped through the code in debug to make sure it didn't head off in  
unexpected directions (eg setProp/getProp handlers) and there was  
nothing of that nature. The writing of the debug information takes  
some time but that should be the same overhead in the IDE and the  
standalone.


Help!

Pete Haworth








___
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: Slow Performance - Update

2010-11-08 Thread Bob Sneidar

You might try opening a low level file and then updating that file with date 
time stamps for every major step you do in the code. That would give you some 
info about where the time is going. 

Bob


On Nov 6, 2010, at 4:23 PM, Peter Haworth wrote:

> I guess I was too hasty in accusing LiveCode 4.5 of performance issues!  I 
> rebuilt my application using Rev Studio 4.0 using the same code base and the 
> performance issues are still there in the standalone.
> 
> So the issue now is that the problem doesn't occur in the IDE, only in the 
> standalone and I don't see any code that distinguishes between the two 
> environments.  I've isolated the problem down to some code that loads entries 
> into option menus by querying my SQLite database.  I've checked the timing of 
> the SQLite query and nothing seems awry there.
> 
> Does anyone have any tips on how to debug something like this in a standalone 
> without using a large number of "answer information" statements or any tips 
> on things that work fine in the IDE but perform slowly in a standalone?  The 
> only major code change I can think of is that I am using the long name of 
> various controls and I used to use the unique ID, but once again why would 
> that cause a problem in a standalone and not in the IDE.
> 
> Any suggestions most welcome!
> 
> Pete Haworth
> 
> 
> 
> 
> 
> 
> 
> ___
> 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: Painfully slow performance (Trevor DeVore)

2010-11-07 Thread Peter Haworth

Thanks for all the input.  I've pretty much ruled out SQLite as the  
cause of the problem because I'm using the same database in the IDE  
and the standalone so unless the standalone is using a different  
SQLite library than the IDE, there shouldn't be any difference in  
performance between the two.


Maybe it would help if I give a little more detail as to what is  
happening on the card.


The basic design of most of my cards involves a datagrid which  
displays summary information about selected table entries.  When the  
user clicks on a row in the datagrid, I get the single entry  
associated with that row from the SQLite table and load information  
from it into controls on the form.  I use naming conventions for the  
controls that allow the code to figure out which column in the table  
entry they are associated with.


The slow down in performance is directly related to the number of  
option buttons on the card - no option buttons, no slowdown.  For a  
card with several option buttons, when I click on a datagrid row in  
the IDE, the update of the controls on the card is instantaneous.   
When I do the same thing in the standalone, the update of the controls  
is painfully slow.  This is using exactly the same data from the same  
database.


The code to handle option buttons simply executes a SELECT statement  
to get data from the database, a simple set statement to set the text  
of the control to the data from the SELECT statement and another  
statement to set the menuhistory of the control using the lineoffset  
function to locate the value of the column in the current table row to  
the text of the control.


Help!


Pete Haworth









___
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

Slow Performance - Update

2010-11-06 Thread Peter Haworth

I guess I was too hasty in accusing LiveCode 4.5 of performance  
issues!  I rebuilt my application using Rev Studio 4.0 using the same  
code base and the performance issues are still there in the standalone.


So the issue now is that the problem doesn't occur in the IDE, only in  
the standalone and I don't see any code that distinguishes between the  
two environments.  I've isolated the problem down to some code that  
loads entries into option menus by querying my SQLite database.  I've  
checked the timing of the SQLite query and nothing seems awry there.


Does anyone have any tips on how to debug something like this in a  
standalone without using a large number of "answer information"  
statements or any tips on things that work fine in the IDE but perform  
slowly in a standalone?  The only major code change I can think of is  
that I am using the long name of various controls and I used to use  
the unique ID, but once again why would that cause a problem in a  
standalone and not in the IDE.


Any suggestions most welcome!

Pete Haworth







___
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: Painfully slow performance

2010-11-06 Thread Trevor DeVore

On Sat, Nov 6, 2010 at 2:30 PM, Peter Haworth wrote:

> I just built my first standalone with LiveCode 4.5 (on OSX) and I'm seeing
> painfully slow performance compared to the same application built with 4.0.
>
> I'm using an SQLite database to populate all the data on the cards in the
> app, not sure if there's some problem with the SQLite side of things.  Only
> other thing I can think of is that I am using several front scripts.
>  Opening a card used to be almost instantaneous, now it's taking 30-45
> seconds.  Bringing up the data for a different SQLite row used to be
> instantaneous, now takes 10 seconds or so.  This is consistant across all
> the cards that handle data fro any table in my SQLite database.
>
> The 4.0 standalone still works just fine using the same database.
>

I recall someone else having an issue with this and reporting it to RQCC but
I can't find the report now. I think the problem was that a field being
search on in the database was not indexed. For some reason there was a slow
down using the newer SQLite driver included with 4.5. Might be worth looking
into.

Regards,


-- 

Trevor DeVore

Blue Mango Learning Systems

www.bluemangolearning.com-www.screensteps.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: Painfully slow performance

2010-11-06 Thread Malte Brill

Peter,

what happens when you use dbsqlite.bundle from the 4.0 release with the 4.5 
engine?

Cheers,

Malte___
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: Painfully slow performance

2010-11-06 Thread Web Admin Himalayan Academy


 On 11/6/10 8:30 AM, Peter Haworth wrote:
I just built my first standalone with LiveCode 4.5 (on OSX) and I'm 
seeing painfully slow performance compared to the same application 
built with 4.0.


I'm using an SQLite database to populate all the data on the cards in 
the app, not sure if there's some problem with the SQLite side of 
things.  Only other thing I can think of is that I am using several 
front scripts.  Opening a card used to be almost instantaneous, now 
it's taking 30-45 seconds.  Bringing up the data for a different 
SQLite row used to be instantaneous, now takes 10 seconds or so.  This 
is consistant across all the cards that handle data fro any table in 
my SQLite database.


The 4.0 standalone still works just fine using the same database.

Any ideas?
Pete Haworth


Disclaimer: this may having nothing to do with your issue and does not 
explain why it was fast before... but still good to remember:


Are you feeding the data to the fields row, by row, or do you get all 
your data into a variable and then post it to the field after the query 
is complete?


this is construct from a sample stack made available in 2006:


  if recNum > 0 then
repeat recNum times
  put empty into tRec
  repeat with c = 1 to colNum
-- put revDatabaseColumnNamed(curID, line c of colNames) & tab 
after tRec

put revDatabaseColumnNumbered(curID, c) & tab after tRec
  end repeat
  put tRec & cr after fld "Select"
  -- revMoveToPreviousRecord curID
  revMoveToNextRecord curID
  if the result = false then exit repeat
end repeat
  end if

this was painfully slow!

when I replaced this line:

put tRec & cr after fld "select"

with

put tRec & cr after tResultSet

end repeat
end if

put tResultSet into fld "select"

the whole thing went from "painfully slow" to "nearly instantaneous"

and I have confirmed this many times: updating a field, line by line is 
hard, for example if your results comprise 650 found rows...  because 
(I'm guessing) you are forcing the stack to update itself 650 times... 
whereas, if you poke a variable and *then* push it to the GUI you are 
asking the stack to only update itself 1 time.


HTH






___
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: Painfully slow performance

2010-11-06 Thread Richard Gaskin


Peter Haworth wrote:


I just built my first standalone with LiveCode 4.5 (on OSX) and I'm
seeing painfully slow performance compared to the same application
built with 4.0.

I'm using an SQLite database to populate all the data on the cards in
the app, not sure if there's some problem with the SQLite side of
things.  Only other thing I can think of is that I am using several
front scripts.  Opening a card used to be almost instantaneous, now
it's taking 30-45 seconds.  Bringing up the data for a different
SQLite row used to be instantaneous, now takes 10 seconds or so.  This
is consistant across all the cards that handle data fro any table in
my SQLite database.

The 4.0 standalone still works just fine using the same database.


I haven't spent a lot of time with SQLite in Rev so I can't comment and 
that and look forward to feedback from others on that front.  But FWIW 
in most general areas I find performance in v4.5 to be on par or 
slightly better than in v4.0.


One think I recently discovered is how so many things related to screen 
updates slow to a crawl the moment you use any controls with graphic 
effects.


I've submitted a proposed solution to the RQCC for regaining the lost 
performance:

<http://quality.runrev.com/qacenter/show_bug.cgi?id=9113>

But unless you changed any objects between those two versions so that 
you're now using graphic effects that you hadn't previously used, I'm at 
a loss to explain the speed difference.


I look forward to seeing what this discussion reveals.

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.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

Painfully slow performance

2010-11-06 Thread Peter Haworth

I just built my first standalone with LiveCode 4.5 (on OSX) and I'm  
seeing painfully slow performance compared to the same application  
built with 4.0.


I'm using an SQLite database to populate all the data on the cards in  
the app, not sure if there's some problem with the SQLite side of  
things.  Only other thing I can think of is that I am using several  
front scripts.  Opening a card used to be almost instantaneous, now  
it's taking 30-45 seconds.  Bringing up the data for a different  
SQLite row used to be instantaneous, now takes 10 seconds or so.  This  
is consistant across all the cards that handle data fro any table in  
my SQLite database.


The 4.0 standalone still works just fine using the same database.

Any ideas?

Pete Haworth









___
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: Performance issues, perhaps Windows 7 related

2010-10-05 Thread David Beck




Thanks Mark. I am having the client give it a try and will let you know 
how it goes.


David Beck
Rotunda Software
___
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: Performance issues, perhaps Windows 7 related

2010-10-04 Thread J. Landman Gay


On 10/4/10 6:57 PM, Mark Wieder wrote:

Jacque-

Monday, October 4, 2010, 2:27:08 PM, you wrote:


Wow, who woulda thought? Video driver issues cause file dialog problems?
I believe you, but I can't imagine why that would be. Any idea?


Absolutely none. Just passing on what I've been told.



I wrote it down in my Weird Tales and Strange Associations diary. Thanks 
though. I've passed the info to my client. He didn't even blink.


--
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: Performance issues, perhaps Windows 7 related

2010-10-04 Thread Mark Wieder

Jacque-

Monday, October 4, 2010, 2:27:08 PM, you wrote:

> Wow, who woulda thought? Video driver issues cause file dialog problems?
> I believe you, but I can't imagine why that would be. Any idea?

Absolutely none. Just passing on what I've been told.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Performance issues, perhaps Windows 7 related

2010-10-04 Thread J. Landman Gay


On 10/4/10 12:39 PM, Mark Wieder wrote:

David-

Monday, October 4, 2010, 10:18:03 AM, you wrote:


Has anybody else experiences this issue or have any ideas about what
could be the cause?


Try upgrading the Win7 video drivers (!)



Wow, who woulda thought? Video driver issues cause file dialog problems? 
I believe you, but I can't imagine why that would be. Any idea?


--
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: Performance issues, perhaps Windows 7 related

2010-10-04 Thread J. Landman Gay


On 10/4/10 12:18 PM, David Beck wrote:


Hello,

I have had two clients report serious performance problems with a
LiveCode standalone application on Windows 7, 32-bit machines. Dialogs
and windows take several minutes to open, when usually they take only
seconds. The same standalone (with the same data) works fine on other
machines. I have never encountered this issue before, and since these
two cases where both on Windows 7 I wonder if the problem is related to
Windows 7.

Has anybody else experiences this issue or have any ideas about what
could be the cause?


I don't know the cause, but I also have a client who reports that on 
Win7 "nothing happens" when he clicks either of two buttons that call 
"ask file" or "answer file" dialogs. Given what you said, I wonder if 
"nothing happens" really means "nothing happens for a long time until I 
get bored and quit."


--
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: Performance issues, perhaps Windows 7 related

2010-10-04 Thread Mark Wieder

David-

Monday, October 4, 2010, 10:18:03 AM, you wrote:

> Has anybody else experiences this issue or have any ideas about what
> could be the cause?

Try upgrading the Win7 video drivers (!)

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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

Performance issues, perhaps Windows 7 related

2010-10-04 Thread David Beck



Hello,

I have had two clients report serious performance problems with a 
LiveCode standalone application on Windows 7, 32-bit machines. Dialogs 
and windows take several minutes to open, when usually they take only 
seconds. The same standalone (with the same data) works fine on other 
machines. I have never encountered this issue before, and since these 
two cases where both on Windows 7 I wonder if the problem is related to 
Windows 7.


Has anybody else experiences this issue or have any ideas about what 
could be the cause?


Thanks very much!

David Beck
Rotunda Software
___
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: Performance

2010-06-21 Thread Peter Brigham MD

A more efficient way of doing this would be to group the buttons and  
set the backcolor of each button to empty, then just

   set the backcolor of group "myBtnGroup" to 89,149,218
and all the objects in the group will inherit the backcolor of the  
group (as long as they don't have an individual backcolor set). Note  
that for this to have visible effect for buttons, they must be opaque


-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig


On Jun 20, 2010, at 9:07 AM, René Micout wrote:


I have also this case : no variable but object (button) name :

  repeat with i = 1 to 21
 put "set the backColor of btn" && quote & "btnHarmo"& i & quote  
&& "to" into vxA ; do vxA

  end repeat

is array solution possible ?

or it is necessary to do :

set the backColor of btn "btnHarmo1" to 89,149,218
set the backColor of btn "btnHarmo2" to 89,149,218
set the backColor of btn "btnHarmo3" to 89,149,218
...
...
set the backColor of btn "btnHarmo21" to 89,149,218


Le 20 juin 2010 à 13:18, Jim Ault a écrit :


In this case I would use an array
or custom properties.  Much faster by far.

--variable array
add one to vgCpuFlux[ vpNumFlux ]


--custom property ( a trickier technique, but more powerful )

 get the vgCpuFlux[ vpNumFlux ] of this stack +1
 set the vgCpuFlux[ vpNumFlux ] of this stack to IT

--or store on each card
 get the vgCpuFlux[ vpNumFlux ] of this CARD +1
 set the vgCpuFlux[ vpNumFlux ] of this CARD to IT

-
The array method takes 1 tick to do 10,000 times
 put "4" into vpNumFlux
 put the ticks into startt
 repeat 1 times
add one to vgCpuFlux[ vpNumFlux ]
 end repeat
 get the ticks - startt
 get IT & cr & vgCpuFlux[ vpNumFlux ]
 answer IT -- => 1   yep only one tick


The custom property method takes 14 ticks to do
 put "4" into vpNumFlux
 put the ticks into startt
 repeat 1 times
 get the vgCpuFlux[ vpNumFlux ] of this stack + 1
set the vgCpuFlux[ vpNumFlux ] of this stack to IT
 end repeat
 get the ticks - startt
 get IT & cr & the vgCpuFlux[ vpNumFlux ] of this stack
 answer IT -- => 14 ticks

The 'do' command should not be used for simply adding numbers such  
as a cross-tabulation technique like you are employing.

Hope this helps.


On Jun 20, 2010, at 3:38 AM, René Micout wrote:


Thank you Mark,
In my project I use lot of "do" command...
For you, is that (the number of flux (flows) is 5) :

put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA

faster or slower than :

switch vpNuméroduFlux
case 1 ; add 1 to vgCompteurFlux1 ; break
case 2 ; add 1 to vgCompteurFlux2 ; break
case 3 ; add 1 to vgCompteurFlux3 ; break
case 4 ; add 1 to vgCompteurFlux4 ; break
case 5 ; add 1 to vgCompteurFlux5 ; break..
end switch

You can answer to me : make a test ;-)... But have you ever had  
this choice to make ?




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


___
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: Performance

2010-06-20 Thread Chipp Walters

Hi René,

Here is also another way to accomplish a similar task when you are trying to 
set the same property of many objects.

put "name,address,city,state,country" into tItems
repeat for each item I in tItems
   set the textfont of field I to "Verdana"
   set the fontsize of field I to 9
end repeat

Chipp Walters
CEO, Shafer Walters Group, Inc

On Jun 20, 2010, at 8:21 AM, René Micout  wrote:

> YES !
> That seems obvious when one sees !
> It is sometimes necessary to step aside to see what is right before us.
> Hartelijk dank
> 
> Le 20 juin 2010 à 15:15, Mark Schonewille a écrit :
> 
>> René,
>> 
>> repeat with i = 1 to 21
>> put "btnHarmo" & i into myBtn
>> set the backColor of btn myBtn to 89,149,218
>> end repeat
>> 
>> --
>> Best regards,
>> 
>> Mark Schonewille
>> 
>> Economy-x-Talk Consulting and Software Engineering
>> Homepage: http://economy-x-talk.com
>> Twitter: http://twitter.com/xtalkprogrammer
>> 
>> Subscribe to the Economy-x-Talk newsletter at http://qurl.tk/cj
>> Download Clipboard Link http://clipboardlink.economy-x-talk.com and share 
>> the clipboard of your computer over the local network.
>> 
>> On 20 jun 2010, at 15:07, René Micout wrote:
>> 
>>> I have also this case : no variable but object (button) name :
>>> 
>>> repeat with i = 1 to 21
>>>put "set the backColor of btn" && quote & "btnHarmo"& i & quote && "to 
>>> 89,149,218" into vxA ; do vxA
>>> end repeat
>>> 
>>> is array solution possible ?
>>> 
>>> or it is necessary to do :
>>> 
>>> set the backColor of btn "btnHarmo1" to 89,149,218
>>> set the backColor of btn "btnHarmo2" to 89,149,218
>>> set the backColor of btn "btnHarmo3" to 89,149,218
>>> ...
>>> ...
>>> set the backColor of btn "btnHarmo21" to 89,149,218
>>> 
>>> 
>> 
>> ___
>> 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: Performance

2010-06-20 Thread Jim Ault


Thierry gave you the answer earlier today with a repeat loop.
The better solution would not use an array for this task.

On Jun 20, 2010, at 6:07 AM, René Micout wrote:


I have also this case : no variable but object (button) name :

  repeat with i = 1 to 21
 put "set the backColor of btn" && quote & "btnHarmo"& i & quote  
&& "to 89,149,218" into vxA ; do vxA

  end repeat

is array solution possible ?

or it is necessary to do :

set the backColor of btn "btnHarmo1" to 89,149,218
set the backColor of btn "btnHarmo2" to 89,149,218
set the backColor of btn "btnHarmo3" to 89,149,218
...
...
set the backColor of btn "btnHarmo21" to 89,149,218



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: Performance

Même réponse que Mark donc même merci (mais en français !)
Bon souvenir de Paris
René

Le 20 juin 2010 à 15:19, Thierry a écrit :

> 
> Le 20 juin 2010 à 15:07, René Micout a écrit :
> 
>> I have also this case : no variable but object (button) name :
>> 
>>  repeat with i = 1 to 21
>> put "set the backColor of btn" && quote & "btnHarmo"& i & quote && "to 
>> 89,149,218" into vxA ; do vxA
>>  end repeat
> 
> meme effet que ton code, sans le DO, donc plus rapide
> et surement plus simple a lire...
> 
>  repeat with i = 1 to 21
> set the backColor of btn ("btnHarmo"& i ) to 89,149,218
>  end repeat
> 
> 
> Cordialement
> Thierry
> 
> ___
> 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: Performance

YES !
That seems obvious when one sees !
It is sometimes necessary to step aside to see what is right before us.
Hartelijk dank

Le 20 juin 2010 à 15:15, Mark Schonewille a écrit :

> René,
> 
> repeat with i = 1 to 21
>  put "btnHarmo" & i into myBtn
>  set the backColor of btn myBtn to 89,149,218
> end repeat
> 
> --
> Best regards,
> 
> Mark Schonewille
> 
> Economy-x-Talk Consulting and Software Engineering
> Homepage: http://economy-x-talk.com
> Twitter: http://twitter.com/xtalkprogrammer
> 
> Subscribe to the Economy-x-Talk newsletter at http://qurl.tk/cj
> Download Clipboard Link http://clipboardlink.economy-x-talk.com and share the 
> clipboard of your computer over the local network.
> 
> On 20 jun 2010, at 15:07, René Micout wrote:
> 
>> I have also this case : no variable but object (button) name :
>> 
>>  repeat with i = 1 to 21
>> put "set the backColor of btn" && quote & "btnHarmo"& i & quote && "to 
>> 89,149,218" into vxA ; do vxA
>>  end repeat
>> 
>> is array solution possible ?
>> 
>> or it is necessary to do :
>> 
>> set the backColor of btn "btnHarmo1" to 89,149,218
>> set the backColor of btn "btnHarmo2" to 89,149,218
>> set the backColor of btn "btnHarmo3" to 89,149,218
>> ...
>> ...
>> set the backColor of btn "btnHarmo21" to 89,149,218
>> 
>> 
> 
> ___
> 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: Performance

2010-06-20 Thread Thierry


Le 20 juin 2010 à 15:07, René Micout a écrit :

> I have also this case : no variable but object (button) name :
> 
>   repeat with i = 1 to 21
>  put "set the backColor of btn" && quote & "btnHarmo"& i & quote && "to 
> 89,149,218" into vxA ; do vxA
>   end repeat

meme effet que ton code, sans le DO, donc plus rapide
et surement plus simple a lire...

  repeat with i = 1 to 21
 set the backColor of btn ("btnHarmo"& i ) to 89,149,218
  end repeat


Cordialement
Thierry

___
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: Performance

2010-06-20 Thread Mark Schonewille


René,

repeat with i = 1 to 21
  put "btnHarmo" & i into myBtn
  set the backColor of btn myBtn to 89,149,218
end repeat

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Subscribe to the Economy-x-Talk newsletter at http://qurl.tk/cj
Download Clipboard Link http://clipboardlink.economy-x-talk.com and  
share the clipboard of your computer over the local network.


On 20 jun 2010, at 15:07, René Micout wrote:


I have also this case : no variable but object (button) name :

  repeat with i = 1 to 21
 put "set the backColor of btn" && quote & "btnHarmo"& i & quote  
&& "to 89,149,218" into vxA ; do vxA

  end repeat

is array solution possible ?

or it is necessary to do :

set the backColor of btn "btnHarmo1" to 89,149,218
set the backColor of btn "btnHarmo2" to 89,149,218
set the backColor of btn "btnHarmo3" to 89,149,218
...
...
set the backColor of btn "btnHarmo21" to 89,149,218




___
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: Performance

I have also this case : no variable but object (button) name :

   repeat with i = 1 to 21
  put "set the backColor of btn" && quote & "btnHarmo"& i & quote && "to 
89,149,218" into vxA ; do vxA
   end repeat

is array solution possible ?

or it is necessary to do :

set the backColor of btn "btnHarmo1" to 89,149,218
set the backColor of btn "btnHarmo2" to 89,149,218
set the backColor of btn "btnHarmo3" to 89,149,218
...
...
set the backColor of btn "btnHarmo21" to 89,149,218


Le 20 juin 2010 à 13:18, Jim Ault a écrit :

> In this case I would use an array
> or custom properties.  Much faster by far.
> 
> --variable array
> add one to vgCpuFlux[ vpNumFlux ]
> 
> 
> --custom property ( a trickier technique, but more powerful )
> 
>   get the vgCpuFlux[ vpNumFlux ] of this stack +1
>   set the vgCpuFlux[ vpNumFlux ] of this stack to IT
> 
> --or store on each card
>   get the vgCpuFlux[ vpNumFlux ] of this CARD +1
>   set the vgCpuFlux[ vpNumFlux ] of this CARD to IT
> 
> -
> The array method takes 1 tick to do 10,000 times
>   put "4" into vpNumFlux
>   put the ticks into startt
>   repeat 1 times
>  add one to vgCpuFlux[ vpNumFlux ]
>   end repeat
>   get the ticks - startt
>   get IT & cr & vgCpuFlux[ vpNumFlux ]
>   answer IT -- => 1   yep only one tick
> 
> 
> The custom property method takes 14 ticks to do
>   put "4" into vpNumFlux
>   put the ticks into startt
>   repeat 1 times
>   get the vgCpuFlux[ vpNumFlux ] of this stack + 1
>  set the vgCpuFlux[ vpNumFlux ] of this stack to IT
>   end repeat
>   get the ticks - startt
>   get IT & cr & the vgCpuFlux[ vpNumFlux ] of this stack
>   answer IT -- => 14 ticks
> 
> The 'do' command should not be used for simply adding numbers such as a 
> cross-tabulation technique like you are employing.
> Hope this helps.
> 
> 
> On Jun 20, 2010, at 3:38 AM, René Micout wrote:
> 
>> Thank you Mark,
>> In my project I use lot of "do" command...
>> For you, is that (the number of flux (flows) is 5) :
>> 
>> put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA
>> 
>> faster or slower than :
>> 
>> switch vpNuméroduFlux
>> case 1 ; add 1 to vgCompteurFlux1 ; break
>> case 2 ; add 1 to vgCompteurFlux2 ; break
>> case 3 ; add 1 to vgCompteurFlux3 ; break
>> case 4 ; add 1 to vgCompteurFlux4 ; break
>> case 5 ; add 1 to vgCompteurFlux5 ; break..
>> end switch
>> 
>> You can answer to me : make a test ;-)... But have you ever had this choice 
>> to make ?
>> 
> 
> 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: Performance

Thank you very much Jim !

Le 20 juin 2010 à 13:18, Jim Ault a écrit :

> In this case I would use an array
> or custom properties.  Much faster by far.
> 
> --variable array
> add one to vgCpuFlux[ vpNumFlux ]
> 
> 
> --custom property ( a trickier technique, but more powerful )
> 
>   get the vgCpuFlux[ vpNumFlux ] of this stack +1
>   set the vgCpuFlux[ vpNumFlux ] of this stack to IT
> 
> --or store on each card
>   get the vgCpuFlux[ vpNumFlux ] of this CARD +1
>   set the vgCpuFlux[ vpNumFlux ] of this CARD to IT
> 
> -
> The array method takes 1 tick to do 10,000 times
>   put "4" into vpNumFlux
>   put the ticks into startt
>   repeat 1 times
>  add one to vgCpuFlux[ vpNumFlux ]
>   end repeat
>   get the ticks - startt
>   get IT & cr & vgCpuFlux[ vpNumFlux ]
>   answer IT -- => 1   yep only one tick
> 
> 
> The custom property method takes 14 ticks to do
>   put "4" into vpNumFlux
>   put the ticks into startt
>   repeat 1 times
>   get the vgCpuFlux[ vpNumFlux ] of this stack + 1
>  set the vgCpuFlux[ vpNumFlux ] of this stack to IT
>   end repeat
>   get the ticks - startt
>   get IT & cr & the vgCpuFlux[ vpNumFlux ] of this stack
>   answer IT -- => 14 ticks
> 
> The 'do' command should not be used for simply adding numbers such as a 
> cross-tabulation technique like you are employing.
> Hope this helps.
> 
> 
> On Jun 20, 2010, at 3:38 AM, René Micout wrote:
> 
>> Thank you Mark,
>> In my project I use lot of "do" command...
>> For you, is that (the number of flux (flows) is 5) :
>> 
>> put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA
>> 
>> faster or slower than :
>> 
>> switch vpNuméroduFlux
>> case 1 ; add 1 to vgCompteurFlux1 ; break
>> case 2 ; add 1 to vgCompteurFlux2 ; break
>> case 3 ; add 1 to vgCompteurFlux3 ; break
>> case 4 ; add 1 to vgCompteurFlux4 ; break
>> case 5 ; add 1 to vgCompteurFlux5 ; break..
>> end switch
>> 
>> You can answer to me : make a test ;-)... But have you ever had this choice 
>> to make ?
>> 
> 
> 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: Performance

Thank you Mark,
Perhaps some milliseconds won... :-)
I understand about using (or not using) "é", but all work well...
without "accents" it is not possible to write french words...
Do you think that can have consequences about performance ?
René

Le 20 juin 2010 à 13:07, Mark Schonewille a écrit :

> René,
> 
> Case will definitely be faster. A good alternative would be:
> 
> add 1 to vgCompteurFlux[vpNumeroduFlux]
> 
> I wouldn't use special characters such as é in variable names. I very rarely 
> have to make such choices, because I have a different syle of programming.
> 
> --
> Best regards,
> 
> Mark Schonewille
> 
> Economy-x-Talk Consulting and Software Engineering
> Homepage: http://economy-x-talk.com
> Twitter: http://twitter.com/xtalkprogrammer
> 
> Subscribe to the Economy-x-Talk newsletter at http://qurl.tk/cj
> Download Clipboard Link http://clipboardlink.economy-x-talk.com and share the 
> clipboard of your computer over the local network.
> 
> On 20 jun 2010, at 12:38, René Micout wrote:
> 
>> Thank you Mark,
>> In my project I use lot of "do" command...
>> For you, is that (the number of flux (flows) is 5) :
>> 
>> put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA
>> 
>> faster or slower than :
>> 
>> switch vpNuméroduFlux
>> case 1 ; add 1 to vgCompteurFlux1 ; break
>> case 2 ; add 1 to vgCompteurFlux2 ; break
>> case 3 ; add 1 to vgCompteurFlux3 ; break
>> case 4 ; add 1 to vgCompteurFlux4 ; break
>> case 5 ; add 1 to vgCompteurFlux5 ; break..
>> end switch
>> 
>> You can answer to me : make a test ;-)... But have you ever had this choice 
>> to make ?
> 
> ___
> 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: Performance

2010-06-20 Thread Jim Ault


In this case I would use an array
or custom properties.  Much faster by far.

--variable array
add one to vgCpuFlux[ vpNumFlux ]


--custom property ( a trickier technique, but more powerful )

   get the vgCpuFlux[ vpNumFlux ] of this stack +1
   set the vgCpuFlux[ vpNumFlux ] of this stack to IT

--or store on each card
   get the vgCpuFlux[ vpNumFlux ] of this CARD +1
   set the vgCpuFlux[ vpNumFlux ] of this CARD to IT

-
The array method takes 1 tick to do 10,000 times
   put "4" into vpNumFlux
   put the ticks into startt
   repeat 1 times
  add one to vgCpuFlux[ vpNumFlux ]
   end repeat
   get the ticks - startt
   get IT & cr & vgCpuFlux[ vpNumFlux ]
   answer IT -- => 1   yep only one tick


The custom property method takes 14 ticks to do
   put "4" into vpNumFlux
   put the ticks into startt
   repeat 1 times
   get the vgCpuFlux[ vpNumFlux ] of this stack + 1
  set the vgCpuFlux[ vpNumFlux ] of this stack to IT
   end repeat
   get the ticks - startt
   get IT & cr & the vgCpuFlux[ vpNumFlux ] of this stack
   answer IT -- => 14 ticks

The 'do' command should not be used for simply adding numbers such as  
a cross-tabulation technique like you are employing.

Hope this helps.


On Jun 20, 2010, at 3:38 AM, René Micout wrote:


Thank you Mark,
In my project I use lot of "do" command...
For you, is that (the number of flux (flows) is 5) :

put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA

faster or slower than :

switch vpNuméroduFlux
case 1 ; add 1 to vgCompteurFlux1 ; break
case 2 ; add 1 to vgCompteurFlux2 ; break
case 3 ; add 1 to vgCompteurFlux3 ; break
case 4 ; add 1 to vgCompteurFlux4 ; break
case 5 ; add 1 to vgCompteurFlux5 ; break..
end switch

You can answer to me : make a test ;-)... But have you ever had this  
choice to make ?




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: Performance

2010-06-20 Thread Richmond


On 06/20/2010 01:11 PM, Mark Schonewille wrote:

Hi René,

Quoted strings can't be interpreted as variables by the engine (as 
long as quoted strings aren't numbers used as names for objects). For 
me, this is the main reason to always put strings in quotes (besides 
the fact that strings with spaces in them will cause errors if there 
are no quotes around them).


The number of characters of variables doesn't matter. Longer variables 
and object names just make your stack file slightly bigger. The effect 
is negligible.


Fast compilation is not the same as fast running. Compilation time is 
negligible, the only noticeable delay may come from the time needed to 
read a file from disk. Of course, long repeat loops and generally bad 
scripting may cause delays too.


RunRev compiles your scripts when the stack file opens. As long as you 
don't edit your scripts, it won't compile them again (with a few 
exceptions, e.g. if you're using the "do" command).




I got in trouble recently with an enormous script I stored in a field 
(thousands of lines) on the
understanding (false) that things were more economical like that rather 
than duplicating the
script across 15 buttons. Because the script was stored in a fld it had 
to be compiled dynamically everytime
it was needed by a "DO" command; but it DIDN'T, so DON"T store scripts 
in 'funny' places and DON'T
use "DO' commands; they are very nearly fatal except for little1 or 2 
liners - at which point the 'economy'

argument collapses.
___
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: Performance

2010-06-20 Thread Mark Schonewille


René,

Case will definitely be faster. A good alternative would be:

add 1 to vgCompteurFlux[vpNumeroduFlux]

I wouldn't use special characters such as é in variable names. I very  
rarely have to make such choices, because I have a different syle of  
programming.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Subscribe to the Economy-x-Talk newsletter at http://qurl.tk/cj
Download Clipboard Link http://clipboardlink.economy-x-talk.com and  
share the clipboard of your computer over the local network.


On 20 jun 2010, at 12:38, René Micout wrote:


Thank you Mark,
In my project I use lot of "do" command...
For you, is that (the number of flux (flows) is 5) :

put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA

faster or slower than :

switch vpNuméroduFlux
case 1 ; add 1 to vgCompteurFlux1 ; break
case 2 ; add 1 to vgCompteurFlux2 ; break
case 3 ; add 1 to vgCompteurFlux3 ; break
case 4 ; add 1 to vgCompteurFlux4 ; break
case 5 ; add 1 to vgCompteurFlux5 ; break..
end switch

You can answer to me : make a test ;-)... But have you ever had this  
choice to make ?


___
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: Performance

Thank you Mark,
In my project I use lot of "do" command...
For you, is that (the number of flux (flows) is 5) :

put "add 1 to vgCompteurFlux"& vpNuméroduFlux into vxA ; do vxA

faster or slower than :

switch vpNuméroduFlux
 case 1 ; add 1 to vgCompteurFlux1 ; break
 case 2 ; add 1 to vgCompteurFlux2 ; break
 case 3 ; add 1 to vgCompteurFlux3 ; break
 case 4 ; add 1 to vgCompteurFlux4 ; break
 case 5 ; add 1 to vgCompteurFlux5 ; break..
end switch

You can answer to me : make a test ;-)... But have you ever had this choice to 
make ?

Le 20 juin 2010 à 12:11, Mark Schonewille a écrit :

> 
> RunRev compiles your scripts when the stack file opens. As long as you don't 
> edit your scripts, it won't compile them again (with a few exceptions, e.g. 
> if you're using the "do" command).

___
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: Performance

2010-06-20 Thread Mark Schonewille


Hi René,

Quoted strings can't be interpreted as variables by the engine (as  
long as quoted strings aren't numbers used as names for objects). For  
me, this is the main reason to always put strings in quotes (besides  
the fact that strings with spaces in them will cause errors if there  
are no quotes around them).


The number of characters of variables doesn't matter. Longer variables  
and object names just make your stack file slightly bigger. The effect  
is negligible.


Fast compilation is not the same as fast running. Compilation time is  
negligible, the only noticeable delay may come from the time needed to  
read a file from disk. Of course, long repeat loops and generally bad  
scripting may cause delays too.


RunRev compiles your scripts when the stack file opens. As long as you  
don't edit your scripts, it won't compile them again (with a few  
exceptions, e.g. if you're using the "do" command).


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Subscribe to the Economy-x-Talk newsletter at http://qurl.tk/cj
Download Clipboard Link http://clipboardlink.economy-x-talk.com and  
share the clipboard of your computer over the local network.


On 20 jun 2010, at 11:40, René Micout wrote:


Hello,
For my actual project I need (and I search) the better performances  
when my scripts are "running"...

I read in Scripter's Scrapbook :
-  Put names in quotes. They are faster to compile since they are  
not checked as variables first, and you cannot unintentionally  
confuse them with a variable of the same spelling.
-  The fewer the characters, the faster they compile; "num of flds"  
is quicker than "the number of background fields".

My question :
Fast "compile" is it fast "run" ?
in other words : is RunRev "compile" one time when I click in my  
script Editor or compile each time the script is run ?

Fast compiling = (≠) fast running ?
Bon souvenir de Paris



___
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

Performance

Hello,
For my actual project I need (and I search) the better performances when my 
scripts are "running"...
I read in Scripter's Scrapbook :
-  Put names in quotes. They are faster to compile since they are not checked 
as variables first, and you cannot unintentionally confuse them with a variable 
of the same spelling.
-  The fewer the characters, the faster they compile; "num of flds" is quicker 
than "the number of background fields".
My question :
Fast "compile" is it fast "run" ?
in other words : is RunRev "compile" one time when I click in my script Editor 
or compile each time the script is run ?
Fast compiling = (≠) fast running ?
Bon souvenir de Paris
René___
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: Rosetta (system performance hit?)

2010-03-14 Thread Kay C Lan

About the same as running GraphicConverter.

On Sun, Mar 14, 2010 at 5:33 AM, Randall Reetz  wrote:
> Ok, that is the hype.  I have no reason to believe it isn't a good 
> translator.  What I am asking is its impact on the performance of the OS?
> ___
> 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: Rosetta (system performance hit?)

2010-03-13 Thread Mark Schonewille


Hi Randall,

Contrary to the older Classic environment, which allows for running  
Mac OS 9, Rosetta doesn't affect the performance of the operating  
system as a whole. It only slows down PowerPC applications, if you'd  
compare them with native Intel versions of the same applications.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Economy-x-Talk is always looking for new software development  
projects. Feel free to contact me for a quote.


Op 13 mrt 2010, om 22:33 heeft Randall Reetz het volgende geschreven:

Ok, that is the hype.  I have no reason to believe it isn't a good  
translator.  What I am asking is its impact on the performance of  
the OS?



___
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: Rosetta (system performance hit?)

2010-03-13 Thread Randall Reetz

Ok, that is the hype.  I have no reason to believe it isn't a good translator.  
What I am asking is its impact on the performance of the OS?
___
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: Rosetta (system performance hit?)

2010-03-12 Thread René Micout

Hello,

In french : http://www.apple.com/fr/rosetta/
In English : http://www.apple.com/rosetta/ :
Here are all the instructions you’ll need: double-click the application icon. 
Behind the scenes, Rosetta dynamically translates most of your PowerPC-based 
applications to work with your Intel-based Mac. There’s no emulation. No 
second-class status. It looks and feels just like it did before. On a Mac, 
you’d expect nothing less.

Bons souvenirs de Paris
René

Le 13 mars 2010 à 07:43, Randall Reetz a écrit :

> Does anyone know the answer to this system performance hit (running rosetta)?
> ___
> 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: Rosetta (system performance hit?)

2010-03-12 Thread Randall Reetz

Does anyone know the answer to this system performance hit (running rosetta)?
___
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: Rosetta (system performance hit?)

2010-03-12 Thread Jeff Massung

My understanding is that Rosetta is just a PPC (and OS 9) emulator... and a
very good one, too. Having it installed (and no OS 9 apps running) is no
more a performance hit than having Parallels or VMware Fusion installed and
not running.

Jeff M.

On Fri, Mar 12, 2010 at 12:57 PM, Randall Lee Reetz <
rand...@randallreetz.com> wrote:

> Is there one?  Just having it installed?
>
> Randall
> ___
> 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

Rosetta (system performance hit?)

2010-03-12 Thread Randall Lee Reetz

Is there one?  Just having it installed?

Randall
___
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: More on Performance

2010-02-04 Thread J. Landman Gay


Scott Rossi wrote:

What strategies do you employ to get the
best responsiveness out of your apps during tight repeat loops?


You could try putting in a "wait 1 millisecond with messages" somewhere 
in the loop. It yields time to the interface so the controls can respond.


--
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: More on Performance

2010-02-04 Thread René Micout

I use a lot of loop-type "send X in 0 millisec" in my application "Exagofon" 
and I actually noticed that the process (music) was significantly faster when a 
window (Finder [Mac !] for example) hiding the application window, thus 
avoiding the screen refresh. However, I am not yet entered the phase of 
optimization of my code, so I am very interested in suggestions related to this 
post...
Sorry for this no-response
Bons souvenirs de Paris
René

Le 4 févr. 2010 à 11:06, Scott Rossi a écrit :

> I'm wondering if anyone has suggestions for maximizing the responsiveness of
> controls during a tight "send in..." loop.
> 
> I just discovered an odd (but perhaps expected?) relationship between the
> send command and locking the screen.  It seems that placing "send in..."
> within a handler that locks and unlocks the screen significantly increases
> screen refresh performance compared to executing the send AFTER unlocking
> the screen.  I suppose this might be due to Rev being able to cue the next
> send before updating the screen but I would have expected send to operate
> independently of the screen update.
> 
> At first I was thrilled to uncover this, as I've spent the last day trying
> to enhance the performance of a heavily animated stack, but I was quickly
> disappointed to find that controls on the card become extremely sluggish and
> less responsive when the send occurs before the screen unlock.  For example,
> a custom slider bogs down heavily and doesn't respond properly, compared to
> when the send occurs AFTER the screen unlock.
> 
> I tried creating a temporary condition (controlActive) that is established
> when a control is clicked, which the send handler could check and then
> adjust the timing of the unlock screen appropriately.  But so far I'm not
> seeing any change in the (poor) behavior.  I will continue testing.
> 
> Has anybody else run into this?  What strategies do you employ to get the
> best responsiveness out of your apps during tight repeat loops?
> 
> Thanks & 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

More on Performance

2010-02-04 Thread Scott Rossi

I'm wondering if anyone has suggestions for maximizing the responsiveness of
controls during a tight "send in..." loop.

I just discovered an odd (but perhaps expected?) relationship between the
send command and locking the screen.  It seems that placing "send in..."
within a handler that locks and unlocks the screen significantly increases
screen refresh performance compared to executing the send AFTER unlocking
the screen.  I suppose this might be due to Rev being able to cue the next
send before updating the screen but I would have expected send to operate
independently of the screen update.

At first I was thrilled to uncover this, as I've spent the last day trying
to enhance the performance of a heavily animated stack, but I was quickly
disappointed to find that controls on the card become extremely sluggish and
less responsive when the send occurs before the screen unlock.  For example,
a custom slider bogs down heavily and doesn't respond properly, compared to
when the send occurs AFTER the screen unlock.

I tried creating a temporary condition (controlActive) that is established
when a control is clicked, which the send handler could check and then
adjust the timing of the unlock screen appropriately.  But so far I'm not
seeing any change in the (poor) behavior.  I will continue testing.

Has anybody else run into this?  What strategies do you employ to get the
best responsiveness out of your apps during tight repeat loops?

Thanks & 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: Performance of RevMedia on matrix diagonalization

Hi Bernard, you are certianly right about RB. Indeed I am following their
developmentduring the years. I am pretty sure that the same code will be
probably faster in RB than in VB6
but I have yet to decide to buy their compiler.
As you said, what is attractive in RevMedia is its free character and the
fact that one can
write a trully portable app running within any browser. It is also rather
easy to
adopt as a language for teaching programming concepts to people in the
scientific field without
the effort needed with Java or C++. Python is certainly a beautiful language
extremely reach
in features and ad hoc libraries and can be adopted as a general purpose
language also
in a scientific context (Numpy will solve almost all numerical aspects). On
the other hand
I still have to find an easy way to deploy to a final user a complex Python
application which would
be straightforward to install on his/her computer.
Cheers
Piero

2009/8/28 Bernard Devlin 

> Viktoras,
>
> Maybe the wording in the IDE (and maybe the docs) is misleading.
> After all, the button in the script editor says 'compile', not just
> 'save' or 'check syntax'.  It might very well be that it is compiled
> into some form of p-code that doesn't mean that it needs to be
> re-compiled each time the script inside a control is called.  (I
> believe that Python and other scripting languages also compile down to
> some form that doesn't require recompilation - I know that REXX used
> to do this).
>
> If it is compiled then one might well have an expectation that it
> would perform at speeds near to those of VB.  After all, Java is
> compiled to byte code and it performs pretty well these days.
> (Although it hardly seems reasonable to expect a company the size of
> RunRev to be able to optimize cross-platform execution the way that a
> company the size of Sun [with additional help/stimulus from companies
> like IBM/Oracle]).
>
> It might also be interesting/useful for Piero to implement his code in
> RealBasic.  Since it is so close to VB it should be fairly trivial.
> After all, RB  is cross platform and from a small company too.
> Although if Piero is interested in delivering content through a
> browser, then RB may not be of much interest to him even if it is
> faster.
>
> Bernard
>
> On Thu, Aug 27, 2009 at 8:30 PM, viktoras d. wrote:
> > However, please
> > correct me if I am wrong, VB6 is compiled while Revolution is
> interpreted,
> > therefore much slower. Did you try implementing same algorithm in other
> > interpreted languages (javascript, php, perl, etc?) it would be
> interesting
> > to do some benchmarking :-)
> >
> ___
> 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
>



-- 
Prof. Piero Ugliengo
University of Torino
Dip. Chimica IFM,  Via P. Giuria, 7 I-10125 Torino
ITALY
Phone: +39-011-670.4596
FAX:   +39-011-236.4596
E-mail:  piero.uglie...@unito.it
Home page:
http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show?_id=ugliengo&sort=DEFAULT&search=&hits=70
MOLDRAW: http://www.moldraw.unito.it
___
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: Performance of RevMedia on matrix diagonalization

Dear Viktoras, thanks a lot for the suggestions. Yes VB is compiled
(although in a sort of p-code) and it isexpected to be faster than any
scripting language. I did't try to do what you have suggested because I am
not
mastering other languages but VB6 and FORTRAN. I am also convinced that
trying to rewrite matrix algebra using
the very fast routines provided natively by Revolution will improve the
matters a lot. As usual, because I am not
a professional in this field, I have to find some time to do that!
Cheers
Piero

2009/8/27 viktoras d. 

> Hi Piero,
>
> declaring local/global variables in functions and handlers should slightly
> add to speed. Populating arrays in advance with zeros so that array size
> won't change inside loops might also be of some value. However, please
> correct me if I am wrong, VB6 is compiled while Revolution is interpreted,
> therefore much slower. Did you try implementing same algorithm in other
> interpreted languages (javascript, php, perl, etc?) it would be interesting
> to do some benchmarking :-)
>
> Using native functions: matrixMultiply(firstArray, secondArray),
> transpose(array) where possible would also increase speed as they are really
> fast.
>
> Best wishes
> Viktoras
>
> Piero Ugliengo wrote:
>
>> I am completely new to Revolution. I have downloaded the RevMedia alpha
>> version and played a bit with it. I was impressed by how fast I was able
>> to
>> port a little VB6 code to RevMedia. This code diagonalizes a symmetric
>> matrix using the Jacobi algorithm. I checked against the VB6 code and I
>> got
>> exactly the same results in the same number of iterations so that numerics
>> is the same. However the RevMedia code is at least one order of magnitude
>> slower than the VB6 one. For instance a 50x50 matrix is diagonalized in a
>> couple of seconds in VB6 and it tooks more than a minute on RevMedia. I
>> know
>> that RevMedia is not meant for numerical intensive calculations; however,
>> I
>> would like to use it in a scientific teaching context so some power is
>> needed. I wonder if anybody much expert than me can try the code using the
>> most powerful Revolution Studio and if there is a clever way to deal with
>> matrix algebra.
>> The link to download the rev script is here:
>>
>> http://sites.google.com/site/pierougliengo/download-1/test.rev?attredirects=0
>>
>> <
>> http://sites.google.com/site/pierougliengo/download-1/test.rev?attredirects=0
>> >One
>> can set the size of the matrix in the onmouse routine.
>> Thanks a lot
>> _
>> Piero Ugliengo
>>
>>
>>
>
> ___
> 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
>



-- 
Prof. Piero Ugliengo
University of Torino
Dip. Chimica IFM,  Via P. Giuria, 7 I-10125 Torino
ITALY
Phone: +39-011-670.4596
FAX:   +39-011-236.4596
E-mail:  piero.uglie...@unito.it
Home page:
http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show?_id=ugliengo&sort=DEFAULT&search=&hits=70
MOLDRAW: http://www.moldraw.unito.it
___
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: Performance of RevMedia on matrix diagonalization

2009-08-27 Thread Bernard Devlin

Viktoras,

Maybe the wording in the IDE (and maybe the docs) is misleading.
After all, the button in the script editor says 'compile', not just
'save' or 'check syntax'.  It might very well be that it is compiled
into some form of p-code that doesn't mean that it needs to be
re-compiled each time the script inside a control is called.  (I
believe that Python and other scripting languages also compile down to
some form that doesn't require recompilation - I know that REXX used
to do this).

If it is compiled then one might well have an expectation that it
would perform at speeds near to those of VB.  After all, Java is
compiled to byte code and it performs pretty well these days.
(Although it hardly seems reasonable to expect a company the size of
RunRev to be able to optimize cross-platform execution the way that a
company the size of Sun [with additional help/stimulus from companies
like IBM/Oracle]).

It might also be interesting/useful for Piero to implement his code in
RealBasic.  Since it is so close to VB it should be fairly trivial.
After all, RB  is cross platform and from a small company too.
Although if Piero is interested in delivering content through a
browser, then RB may not be of much interest to him even if it is
faster.

Bernard

On Thu, Aug 27, 2009 at 8:30 PM, viktoras d. wrote:
> However, please
> correct me if I am wrong, VB6 is compiled while Revolution is interpreted,
> therefore much slower. Did you try implementing same algorithm in other
> interpreted languages (javascript, php, perl, etc?) it would be interesting
> to do some benchmarking :-)
>
___
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: Performance of RevMedia on matrix diagonalization

2009-08-27 Thread viktoras d.


Hi Piero,

declaring local/global variables in functions and handlers should 
slightly add to speed. Populating arrays in advance with zeros so that 
array size won't change inside loops might also be of some value. 
However, please correct me if I am wrong, VB6 is compiled while 
Revolution is interpreted, therefore much slower. Did you try 
implementing same algorithm in other interpreted languages (javascript, 
php, perl, etc?) it would be interesting to do some benchmarking :-)


Using native functions: matrixMultiply(firstArray, secondArray), 
transpose(array) where possible would also increase speed as they are 
really fast.


Best wishes
Viktoras

Piero Ugliengo wrote:

I am completely new to Revolution. I have downloaded the RevMedia alpha
version and played a bit with it. I was impressed by how fast I was able to
port a little VB6 code to RevMedia. This code diagonalizes a symmetric
matrix using the Jacobi algorithm. I checked against the VB6 code and I got
exactly the same results in the same number of iterations so that numerics
is the same. However the RevMedia code is at least one order of magnitude
slower than the VB6 one. For instance a 50x50 matrix is diagonalized in a
couple of seconds in VB6 and it tooks more than a minute on RevMedia. I know
that RevMedia is not meant for numerical intensive calculations; however, I
would like to use it in a scientific teaching context so some power is
needed. I wonder if anybody much expert than me can try the code using the
most powerful Revolution Studio and if there is a clever way to deal with
matrix algebra.
The link to download the rev script is here:
http://sites.google.com/site/pierougliengo/download-1/test.rev?attredirects=0

One
can set the size of the matrix in the onmouse routine.
Thanks a lot
_
Piero Ugliengo

  


___
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: Performance of RevMedia on matrix diagonalization

Dear Mark, thanks a lot for the advise. Things like 1.0 istead of 1 were
just my ignorance of the language.On the other hand I thought that the
syntax a[i][j] instead of the more readable a[i,j] was imposed by the
language.
Cheers
Piero

2009/8/27 Mark Smith 

> I saw this over on the forum (the diagonalisation takes about twenty
> seconds on my MacBookPro with rev enterprise), and two things occur to me.
>
> 'Arrays' in revolution are actually hash tables, so are very nice for
> random access to elements, but will not be as efficient for sequential
> access as more traditional, fixed width arrays in other languages.
> I suspect that this is the main speed issue with your eigen function.
>
> Secondly, I understand that all numbers in revolution (which is an un-typed
> language) are floats - though there may be conversions to and from integers
> going on in the engine. I doubt that this will have any effect on the speed
> of your functions, but it's probably unneccessary to write '1.0' or '1.' -
> simply '1' will do, I think.
>
> I think that using the a[i][j] approach instead of a[i,j] might get you
> maybe 10% more speed, but then you'd have to convert to a[i,j] anyway in
> order to use the built in matrixmultiply and transpose functions (this
> should be updated, I'd have thought).
>
> My maths is nowhere near good enough to suggest mathematical optimisations
> (which you might not want for educational purposes, anyway) and I can't see
> any obvious optimisations to make in the code you've written.
>
> Hopefully, someone here will be able to be more helpful, but this may be
> one of those things that revolution simply isn't best suited for :(
>
> Best,
>
> Mark Smith
>
>
>
> On 27 Aug 2009, at 08:16, Piero Ugliengo wrote:
>
>  I am completely new to Revolution. I have downloaded the RevMedia alpha
>> version and played a bit with it. I was impressed by how fast I was able
>> to
>> port a little VB6 code to RevMedia. This code diagonalizes a symmetric
>> matrix using the Jacobi algorithm. I checked against the VB6 code and I
>> got
>> exactly the same results in the same number of iterations so that numerics
>> is the same. However the RevMedia code is at least one order of magnitude
>> slower than the VB6 one. For instance a 50x50 matrix is diagonalized in a
>> couple of seconds in VB6 and it tooks more than a minute on RevMedia. I
>> know
>> that RevMedia is not meant for numerical intensive calculations; however,
>> I
>> would like to use it in a scientific teaching context so some power is
>> needed. I wonder if anybody much expert than me can try the code using the
>> most powerful Revolution Studio and if there is a clever way to deal with
>> matrix algebra.
>> The link to download the rev script is here:
>> http://sites.google.com/site/pierougliengo/download-1/test.rev
>> ?attredirects=0
>>
>> > ?attredirects=0>One
>> can set the size of the matrix in the onmouse routine.
>> Thanks a lot
>> _
>> Piero Ugliengo
>>
>> --
>> Prof. Piero Ugliengo
>> University of Torino
>> Dip. Chimica IFM,  Via P. Giuria, 7 I-10125 Torino
>> ITALY
>> Phone: +39-011-670.4596
>> FAX:   +39-011-236.4596
>> E-mail:  piero.uglie...@unito.it
>> Home page:
>> http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show
>> ?_id=ugliengo&sort=DEFAULT&search=&hits=70
>> MOLDRAW: http://www.moldraw.unito.it
>> ___
>> 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
>



-- 
Prof. Piero Ugliengo
University of Torino
Dip. Chimica IFM,  Via P. Giuria, 7 I-10125 Torino
ITALY
Phone: +39-011-670.4596
FAX:   +39-011-236.4596
E-mail:  piero.uglie...@unito.it
Home page:
http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show?_id=ugliengo&sort=DEFAULT&search=&hits=70
MOLDRAW: http://www.moldraw.unito.it
___
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: Performance of RevMedia on matrix diagonalization

2009-08-27 Thread Mark Smith

I saw this over on the forum (the diagonalisation takes about twenty  
seconds on my MacBookPro with rev enterprise), and two things occur  
to me.


'Arrays' in revolution are actually hash tables, so are very nice for  
random access to elements, but will not be as efficient for  
sequential access as more traditional, fixed width arrays in other  
languages.

I suspect that this is the main speed issue with your eigen function.

Secondly, I understand that all numbers in revolution (which is an un- 
typed language) are floats - though there may be conversions to and  
from integers going on in the engine. I doubt that this will have any  
effect on the speed of your functions, but it's probably unneccessary  
to write '1.0' or '1.' - simply '1' will do, I think.


I think that using the a[i][j] approach instead of a[i,j] might get  
you maybe 10% more speed, but then you'd have to convert to a[i,j]  
anyway in order to use the built in matrixmultiply and transpose  
functions (this should be updated, I'd have thought).


My maths is nowhere near good enough to suggest mathematical  
optimisations (which you might not want for educational purposes,  
anyway) and I can't see any obvious optimisations to make in the code  
you've written.


Hopefully, someone here will be able to be more helpful, but this may  
be one of those things that revolution simply isn't best suited for :(


Best,

Mark Smith


On 27 Aug 2009, at 08:16, Piero Ugliengo wrote:

I am completely new to Revolution. I have downloaded the RevMedia  
alpha
version and played a bit with it. I was impressed by how fast I was  
able to

port a little VB6 code to RevMedia. This code diagonalizes a symmetric
matrix using the Jacobi algorithm. I checked against the VB6 code  
and I got
exactly the same results in the same number of iterations so that  
numerics
is the same. However the RevMedia code is at least one order of  
magnitude
slower than the VB6 one. For instance a 50x50 matrix is  
diagonalized in a
couple of seconds in VB6 and it tooks more than a minute on  
RevMedia. I know
that RevMedia is not meant for numerical intensive calculations;  
however, I

would like to use it in a scientific teaching context so some power is
needed. I wonder if anybody much expert than me can try the code  
using the
most powerful Revolution Studio and if there is a clever way to  
deal with

matrix algebra.
The link to download the rev script is here:
http://sites.google.com/site/pierougliengo/download-1/test.rev? 
attredirects=0


One

can set the size of the matrix in the onmouse routine.
Thanks a lot
_
Piero Ugliengo

--
Prof. Piero Ugliengo
University of Torino
Dip. Chimica IFM,  Via P. Giuria, 7 I-10125 Torino
ITALY
Phone: +39-011-670.4596
FAX:   +39-011-236.4596
E-mail:  piero.uglie...@unito.it
Home page:
http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show? 
_id=ugliengo&sort=DEFAULT&search=&hits=70

MOLDRAW: http://www.moldraw.unito.it
___
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: Performance of RevMedia on matrix diagonalization

2009-08-27 Thread Martin Blackman

I just tried it in Rev Studio. Changed 'N' to 50 under mouseup, it
took a shade over 30 seconds to diagonalise, I'm using a 4 year old
AMD 64 3200+.
I'll leave the optimising to others for now..


2009/8/27 Piero Ugliengo :
> I am completely new to Revolution. I have downloaded the RevMedia alpha
> version and played a bit with it. I was impressed by how fast I was able to
> port a little VB6 code to RevMedia. This code diagonalizes a symmetric
> matrix using the Jacobi algorithm. I checked against the VB6 code and I got
> exactly the same results in the same number of iterations so that numerics
> is the same. However the RevMedia code is at least one order of magnitude
> slower than the VB6 one. For instance a 50x50 matrix is diagonalized in a
> couple of seconds in VB6 and it tooks more than a minute on RevMedia. I know
> that RevMedia is not meant for numerical intensive calculations; however, I
> would like to use it in a scientific teaching context so some power is
> needed. I wonder if anybody much expert than me can try the code using the
> most powerful Revolution Studio and if there is a clever way to deal with
> matrix algebra.
> The link to download the rev script is here:
> http://sites.google.com/site/pierougliengo/download-1/test.rev?attredirects=0
>
> One
> can set the size of the matrix in the onmouse routine.
> Thanks a lot
> _
> Piero Ugliengo
>
> --
> Prof. Piero Ugliengo
> University of Torino
> Dip. Chimica IFM,  Via P. Giuria, 7 I-10125 Torino
> ITALY
> Phone: +39-011-670.4596
> FAX:   +39-011-236.4596
> E-mail:  piero.uglie...@unito.it
> Home page:
> http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show?_id=ugliengo&sort=DEFAULT&search=&hits=70
> MOLDRAW: http://www.moldraw.unito.it
> ___
> 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

Performance of RevMedia on matrix diagonalization

I am completely new to Revolution. I have downloaded the RevMedia alpha
version and played a bit with it. I was impressed by how fast I was able to
port a little VB6 code to RevMedia. This code diagonalizes a symmetric
matrix using the Jacobi algorithm. I checked against the VB6 code and I got
exactly the same results in the same number of iterations so that numerics
is the same. However the RevMedia code is at least one order of magnitude
slower than the VB6 one. For instance a 50x50 matrix is diagonalized in a
couple of seconds in VB6 and it tooks more than a minute on RevMedia. I know
that RevMedia is not meant for numerical intensive calculations; however, I
would like to use it in a scientific teaching context so some power is
needed. I wonder if anybody much expert than me can try the code using the
most powerful Revolution Studio and if there is a clever way to deal with
matrix algebra.
The link to download the rev script is here:
http://sites.google.com/site/pierougliengo/download-1/test.rev?attredirects=0

One
can set the size of the matrix in the onmouse routine.
Thanks a lot
_
Piero Ugliengo

--
Prof. Piero Ugliengo
University of Torino
Dip. Chimica IFM, Via P. Giuria, 7 I-10125 Torino
ITALY
Phone: +39-011-670.4596
FAX: +39-011-236.4596
E-mail: piero.uglie...@unito.it
Home page:
http://web086.unito.it/cgi-bin/chimifm/persone.pl/Show?_id=ugliengo&sort=DEFAULT&search=&hits=70
MOLDRAW: http://www.moldraw.unito.it
___
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

Benchmark: Behavior script access performance

2009-03-11 Thread Richard Gaskin

Benchmarking fiend that I am, I was curious about the overhead of 
calling a hander in a behavior script in v3.5 as opposed to the closest 
approximation in 3.0 and earlier, a backScript which differentiates 
which objects it works on based on a custom property value.


For those unaware that v3.5 is in beta testing, Kevin introduced it in a 
recent newsletter:

<http://runrev.com/newsletter/february/issue65/newsletter1.php>

Trevor goes into detail here:
<http://runrev.com/newsletter/february/issue65/newsletter2.php>

In brief, in v3.5 you can use the script of any button to define 
behavior for any other object, enhancing the message path like this:


   
   
   
   

Messages sent to an object go first to that object, and then to whatever
button script is assigned as that object's behavior.  After the behavior 
script they resume the normal message path.


In v3.0 and earlier the closest thing we had was using a backScript and 
then differentiating whether a handler should run or not based on the 
value of a custom property.  That was reasonably fast enough, but I 
wondered if behaviors would be any faster.


So in v3.5b I made a stack with three buttons:

button 1 has a uClass property set to "b", with this benchmarking script:

on mouseUp
  put 1 into n
  -- Behavior:
  put the millisecs into t
  repeat n
put foob() into r1
  end repeat
  put the millisecs - t into t1
  -- Backscript:
  put the millisecs into t
  repeat n
put foobs() into r2
  end repeat
  put the millisecs - t into t2
  -- Result:
  put t1 && t2
end mouseUp


Button "b1" is inserted into the backScripts, with his handler:

function foobs
  if the uClass of the target = "b" then
return 1+1
  end if
end foobs


Button "c1" is assigned as the behavior of button 1, with this script:

function foob
  return 1+1
end foob

True, the backScript is being asked to do more work, but it's the 
fairest comparison that way because behavior scripts only apply to 
buttons with a property assigned to them (the behavior property), and do 
not affect others.


So here's the result:

9 30

Behaviors average roughly three times faster to access than functionally 
equivalent backScripts.


And FWIW, if I take out the property check in the backScript (which 
gives the backScript method an unfair advantage), the result is:


9 16

So behaviors still win.  Not surprising, since messages have a shorter 
path to travel to them.


If you're not currently participating in the beta testing for v3.5 just 
sit tight a while longer, it's coming.  And when it's here, the new 
behaviors feature will not only change the way you script, but in some 
cases may boost performance along the way.


It's a mighty fine implementation.  Thanks, RunRev!

--
 Richard Gaskin
 Fourth World
 Revolution training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.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: CGI performance: using mod_cache

2008-06-02 Thread Andre Garzia

David,

I am assuming you have a way to tell if the database changed since you
last poked into it.

Make your cgi generate static pages, this way, and trigger the
regeneration of the pages to new data being inserted onto the
database, this is quick and easy, everytime you enter new data, the
page is generated again.

Most browsers will send some information on the http headers such as
"ETag" or "if-modified-since", meaning, they are checking to see if
the content changed since they last looked into it, you can answer
with a "304 not modified".

If you combine both approaches, you save both your CPU cycles (not
querying the database all the time) and bandwidth (not transfering
webpages that are cached and did not change).

Andre

On Sat, May 31, 2008 at 1:29 AM, David Bovill <[EMAIL PROTECTED]> wrote:
> I'd like to speed up performance of a Rev based CGI by caching the results
> on the server - however I want to retain the CGI based dynamic behaviour.
> >From reading around it looks like this is possible, and I think this could
> be a generally useful hack for Rev based CGI's. AFAIK this is a fairly
> standard issue largely solved by other frameworks.
>
> Here is the scenario:
>
>   1. You have a dynamic cgi that fetches data from a database, munges these
>   up and serves up your page
>   2. The CGI is painfully slow
>   3. It is not possible to optimise the cgi
>   4. You decide to use caching
>   5. But when you update the database you want to the new data to be served
>   - you want to retain the dynamic behavior
>   6. Users need to be able to update the database - so you cant do this
>   with your own code - you need an automatic solution.
>
> I am not sure how to achieve this - but there seem to be the server based
> functionality needed with any new Apache installation. Here are some
> "ideas":
>
>   - The Rev CGI could set HTTP headers depending on if the data in the
>   database had changed (not sure this will work)
>   - The Rev CGI used to update the data (model)
>  - also changes the .htaccess directive
>  - somehow updates the cache
>   - Give up using Apache Cache and simply write the data out to a file -
>   creating and maintaining your own cache
>
> What you want is a robust file based "data_changed" flag - which instructs
> Apache to go fetch new data from the cgi.
>
> It seems that by using simply and carefully the built in Apache Cache
> ability - you should be able to use Revs flexible nature to create complex
> CGI's and not worry too much about optimising them or having to write extra
> code to store and maintain you own files. Any ideas?
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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

CGI performance: using mod_cache

2008-05-31 Thread David Bovill

I'd like to speed up performance of a Rev based CGI by caching the results
on the server - however I want to retain the CGI based dynamic behaviour.
>From reading around it looks like this is possible, and I think this could
be a generally useful hack for Rev based CGI's. AFAIK this is a fairly
standard issue largely solved by other frameworks.

Here is the scenario:

   1. You have a dynamic cgi that fetches data from a database, munges these
   up and serves up your page
   2. The CGI is painfully slow
   3. It is not possible to optimise the cgi
   4. You decide to use caching
   5. But when you update the database you want to the new data to be served
   - you want to retain the dynamic behavior
   6. Users need to be able to update the database - so you cant do this
   with your own code - you need an automatic solution.

I am not sure how to achieve this - but there seem to be the server based
functionality needed with any new Apache installation. Here are some
"ideas":

   - The Rev CGI could set HTTP headers depending on if the data in the
   database had changed (not sure this will work)
   - The Rev CGI used to update the data (model)
  - also changes the .htaccess directive
  - somehow updates the cache
   - Give up using Apache Cache and simply write the data out to a file -
   creating and maintaining your own cache

What you want is a robust file based "data_changed" flag - which instructs
Apache to go fetch new data from the cgi.

It seems that by using simply and carefully the built in Apache Cache
ability - you should be able to use Revs flexible nature to create complex
CGI's and not worry too much about optimising them or having to write extra
code to store and maintain you own files. Any ideas?
___
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: UI performance and large data set in Table Object

2008-03-11 Thread bjdevlin

To be frank, Rev's native table object leaves an awful lot to be desired. 
Quite a few people on this list ended up writing their own table object
instead.  I wrote one with resizable columns and column-click sorting that
was based on a normal scrolling field.  It was lightening fast with
thousands of rows.  

Chipp has made his table control publicly available:
http://www.altuit.com/webs/altuit2/RunRevArchived/Archives.htm and look for
'altFldHeader Control'.  It may well turn out that this serves your needs
better than Rev's table object.

Bernard

mfstuart wrote:
> 
> I also tried the Scrolling Field and compared it to the Table Field, using
> 20,844 lines - big difference, where the Scrolling Field won in it's
> performance of no degradation of stack resize.
> But I've never used this object before, because I lose the formatting of
> columnar presentation.
> 
> If I use this object, is there a way to set it to columnar appearance?
> And isn't it when you check the table property for this object, it changes
> everything back to a Table Field?
> 

-- 
View this message in context: 
http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15629164.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: UI performance and large data set in Table Object

2008-02-22 Thread Richard Gaskin


mfstuart wrote:

As I mentioned in my previous listing, 20, 30, or 5 lines can be found,
depends on the users search criteria. My example was 20,844 lines).
The record length for the table is 255 (counting up the SQL definition
lengths for all columns)
On the stack I'm only using 8 of the 13 columns from the SQL table. The
record length for the Table Field then is 200.

I also tried the Scrolling Field and compared it to the Table Field, using
20,844 lines - big difference, where the Scrolling Field won in it's
performance of no degradation of stack resize.
But I've never used this object before, because I lose the formatting of
columnar presentation.

If I use this object, is there a way to set it to columnar appearance?


The field object was the key to the recipe I provided in my earlier
post, but when I wrote that I forgot to specify "Any text container 
controls other than what the IDE calls a 'Table Object'". :)


The other ingredients in my recipe were to set its hGrid and vGrid
properties. Once you do that, you've just made an engine-native table field.

I don't use the Rev IDE myself, so I've never had occasion to use it's
"Table Object" (I still use the old IDE from before the acquisition,
MetaCard), so I can't guess what it's doing that would eat so much time. 
 But apparently some of the extra properties they set in it trigger a 
lot of other scripts in their libraries.


Does anyone here know what the scripts driving Rev's "Table Object" are 
doing that would require so much processing during resizing?


While there may be some room to optimize some of the scripts in the Rev 
IDE, I have a *lot* of confidence in the Rev engine.  Glad to see you've 
found a solution with it that performs well.



Know the engine.
Trust the engine.
Use the engine.

:)

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.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: UI performance and large data set in Table Object

2008-02-22 Thread Thierry


Hi,



 Hi Sarah,
 That sounds promising, especially reading prior threads on the  
same custom

 property concept.


The data was there already. I actually MOVED it to custom properties
rather than duplicating the data, so the overhead was no worse than it
had been and quite acceptable. The stack ended up at about 6 MB. The
data is not stored forever, it just builds up over 1 - 2 weeks, then
gets cleared and the process starts again.



I did use the same concept for an old project. During development,
all of a project Datas where stored in a folder on an Intranet site,  
to be

shared by multiple computers.

When everything works, and for security, administration and
others reasons I forgot,  I put the contents of a folder in a stack,
no widget, only an empty stack, with no scripts and only customs
properties. One stack contains all the Datas plus Log information plus
extras time Datas,... To choose a project, the user has to choose a  
file,
stored wherever he feels on his disk. These stacks could be more than  
10 Mb,

storing, text, binary datas, logs, images,
I did change the extension of these stacks too... so the users could  
see their

projects as a one file; they like it.

Another thing to say that choosing this architecture, the development  
was short

with almost no debug process !

And if you come from another software planet, customs properties are  
only

associative arrays, no more really.

And the last but not the least, it was before 2000, and, at this  
time, I got so

many clever and good answers from this list...  :-)


HTH,
Have a nice day,

Thierry


___
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: UI performance and large data set in Table Object

2008-02-22 Thread viktoras didziulis


Hi Mark,

use scrolling field object with vgrid and hgrid set to true (table to 
false), so you will get it formatted correctly without all the overheads 
of the table object. I always use this when I need table and it for me 
handles a few thousand records without any slowing downs.


One more option would be to play with LIMIT and OFFSET in SQL SELECT's 
and display only parts of the query that you want to.


All the best
Viktoras


___
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: UI performance and large data set in Table Object

2008-02-21 Thread Stephen Barncard

Table appearance in a scrolling field  can also be accomplished just 
using tabs.


Check out the table pulldown on the object inspector

uncheck table object
check hgrid and or vgrid
grid lines color can be subtle




If I use this object, is there a way to set it to columnar appearance?
And isn't it when you check the table property for this object, it changes
everything back to a Table Field?

Thanx,
Mark Stuart




--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
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: UI performance and large data set in Table Object

Hi Richard,
I'm at home now. looking at this...
As I mentioned in my previous listing, 20, 30, or 5 lines can be found,
depends on the users search criteria. My example was 20,844 lines).
The record length for the table is 255 (counting up the SQL definition
lengths for all columns)
On the stack I'm only using 8 of the 13 columns from the SQL table. The
record length for the Table Field then is 200.

I also tried the Scrolling Field and compared it to the Table Field, using
20,844 lines - big difference, where the Scrolling Field won in it's
performance of no degradation of stack resize.
But I've never used this object before, because I lose the formatting of
columnar presentation.

If I use this object, is there a way to set it to columnar appearance?
And isn't it when you check the table property for this object, it changes
everything back to a Table Field?

Thanx,
Mark Stuart

Richard Gaskin wrote:
> 
> mfstuart wrote:
>> I did as you suggested and copied 8 columns of data (20,844 lines) into
>> this
>> new stack.
>> Just a table object on the card - no scripts (except your 'on
>> resizeStack'
>> in the stack), no other objects.
>> resize result: same slow behavior :(
>> 
>> Any other thoughts on that?
> 
> How much data is in the field?  (How many lines, and average length of 
> the lines)
> 
> -- 
>   Richard Gaskin
>   Managing Editor, revJournal
>   ___
>   Rev tips, tutorials and more: http://www.revJournal.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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15626387.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: UI performance and large data set in Table Object

2008-02-21 Thread Sarah Reichelt

>  Hi Sarah,
>  That sounds promising, especially reading prior threads on the same custom
>  property concept.
>  (A thought on this concept of copying data to a custom property - wouldn't
>  it consume large amounts of the users computer memory/resources?)

The data was there already. I actually MOVED it to custom properties
rather than duplicating the data, so the overhead was no worse than it
had been and quite acceptable. The stack ended up at about 6 MB. The
data is not stored forever, it just builds up over 1 - 2 weeks, then
gets cleared and the process starts again.

>  But this is a multi-user application, where many users will be searching,
>  updating, deleting, and adding records into the SQL database thru this Rev
>  app. It's not a read-only application. I think if it was, the custom
>  property could be worth looking at.
>  Mark Stuart

I still think if you do a query and load the entire result into a
custom property, then show only portions of this data at a time in a
field, you will have the best of both worlds - minimizing the number
of trips to the server and minimizing the display times.

Cheers,
Sarah


>
>  Sarah Reichelt-2 wrote:
>  >
>  > On Fri, Feb 22, 2008 at 9:21 AM, mfstuart <[EMAIL PROTECTED]> wrote:
>  >>
>  >>  I haven't tried storing data in a custom property as yet, but wouldn't
>  >> that
>  >>  render the same lack of performance behavior, where putting the data
>  >> into a
>  >>  stack of the UI?
>  >
>  > No, because the engine doesn't have to think about how to display your
>  > data, it's just storing whatever you put in there.
>  >
>  > I got involved in a project were data was being stored in fields on
>  > another card, so not even visible. The amount of data was getting
>  > quite large, about 40,000 lines in each field. When I changed it to
>  > storing the data in custom properties, the speed of adding new data
>  > points dropped from around 3 seconds to about 5 ticks!
>  >
>  > Cheers,
>  > Sarah
___
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: UI performance and large data set in Table Object

2008-02-21 Thread Brian Yennie


Mark,

Are you using a table object, or a regular scrolling field with the  
hGrid and vGrid properties turned on? The former is an emulated  
control which may slow down significantly, while the latter should be  
significantly faster.


In the past, I've managed to put data on the order of 20 columns /  
100,000 rows into regular fields. I don't recall how snappy things  
were, but I don't remember having problems.


HTH,
Brian



Hi Richard,
I did as you suggested and copied 8 columns of data (20,844 lines)  
into this

new stack.
Just a table object on the card - no scripts (except your 'on  
resizeStack'

in the stack), no other objects.
resize result: same slow behavior :(

Any other thoughts on that?

Mark Stuart




___
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: UI performance and large data set in Table Object

2008-02-21 Thread Richard Gaskin


mfstuart wrote:

I did as you suggested and copied 8 columns of data (20,844 lines) into this
new stack.
Just a table object on the card - no scripts (except your 'on resizeStack'
in the stack), no other objects.
resize result: same slow behavior :(

Any other thoughts on that?


How much data is in the field?  (How many lines, and average length of 
the lines)


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.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: UI performance and large data set in Table Object


Hi Sarah,
That sounds promising, especially reading prior threads on the same custom
property concept.
(A thought on this concept of copying data to a custom property - wouldn't
it consume large amounts of the users computer memory/resources?)

But this is a multi-user application, where many users will be searching,
updating, deleting, and adding records into the SQL database thru this Rev
app. It's not a read-only application. I think if it was, the custom
property could be worth looking at.
Mark Stuart



Sarah Reichelt-2 wrote:
> 
> On Fri, Feb 22, 2008 at 9:21 AM, mfstuart <[EMAIL PROTECTED]> wrote:
>>
>>  I haven't tried storing data in a custom property as yet, but wouldn't
>> that
>>  render the same lack of performance behavior, where putting the data
>> into a
>>  stack of the UI?
> 
> No, because the engine doesn't have to think about how to display your
> data, it's just storing whatever you put in there.
> 
> I got involved in a project were data was being stored in fields on
> another card, so not even visible. The amount of data was getting
> quite large, about 40,000 lines in each field. When I changed it to
> storing the data in custom properties, the speed of adding new data
> points dropped from around 3 seconds to about 5 ticks!
> 
> Cheers,
> Sarah
> ___
> 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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15625210.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: UI performance and large data set in Table Object


Hi Richard,
I did as you suggested and copied 8 columns of data (20,844 lines) into this
new stack.
Just a table object on the card - no scripts (except your 'on resizeStack'
in the stack), no other objects.
resize result: same slow behavior :(

Any other thoughts on that?

Mark Stuart


Richard Gaskin wrote:
> 
> mfstuart wrote:
>> My day job is a software engineer, using another software development
>> tool -
>> eDeveloper.
>> The product we build (CRM) is for enterprise sized companies, working on
>> large amounts of SQL data.
>> eDeveloper does not produce this UI lack of performance during runtime.
>> This
>> is how I noticed the difference in behavior.
>> As far as Excel and Rev, both load the data into memory, which I would
>> assume then declines the available resources, causing the issue at hand.
>> Whereas the table object in our software is reading the data continually
>> (??) from the database, caching when needed, so the lack of performance
>> is
>> never noticed.
> 
> Rev fields are smartly buffered and tend to redraw faster than any other 
> app on my hard drive.  If you're seeing unusually slow redraws it may be 
> related to Rev libraries rather than the engine itself.
> 
> Try this:  Make a new stack, add a field, turn on the field's hGrid and 
> vGrid properties, and dump an equivalent amount of data into it.
> 
> To handle the resize, use this rather than Rev's Geometry Manager:
> 
> on resizeStack x,y
> set the rect of fld 1 to 20,20,x-20,y-20
> end resizeStack
> 
> 
> If Rev is as efficient as I think it is, that test should show a pretty 
> smooth update.  If not we can look into it more deeply.
> 
> -- 
>   Richard Gaskin
>   Managing Editor, revJournal
>   ___
>   Rev tips, tutorials and more: http://www.revJournal.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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15625188.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: UI performance and large data set in Table Object

2008-02-21 Thread Richard Gaskin


mfstuart wrote:

My day job is a software engineer, using another software development tool -
eDeveloper.
The product we build (CRM) is for enterprise sized companies, working on
large amounts of SQL data.
eDeveloper does not produce this UI lack of performance during runtime. This
is how I noticed the difference in behavior.
As far as Excel and Rev, both load the data into memory, which I would
assume then declines the available resources, causing the issue at hand.
Whereas the table object in our software is reading the data continually
(??) from the database, caching when needed, so the lack of performance is
never noticed.


Rev fields are smartly buffered and tend to redraw faster than any other 
app on my hard drive.  If you're seeing unusually slow redraws it may be 
related to Rev libraries rather than the engine itself.


Try this:  Make a new stack, add a field, turn on the field's hGrid and 
vGrid properties, and dump an equivalent amount of data into it.


To handle the resize, use this rather than Rev's Geometry Manager:

on resizeStack x,y
   set the rect of fld 1 to 20,20,x-20,y-20
end resizeStack


If Rev is as efficient as I think it is, that test should show a pretty 
smooth update.  If not we can look into it more deeply.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.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: UI performance and large data set in Table Object


Hi Richard,
My day job is a software engineer, using another software development tool -
eDeveloper.
The product we build (CRM) is for enterprise sized companies, working on
large amounts of SQL data.
eDeveloper does not produce this UI lack of performance during runtime. This
is how I noticed the difference in behavior.
As far as Excel and Rev, both load the data into memory, which I would
assume then declines the available resources, causing the issue at hand.
Whereas the table object in our software is reading the data continually
(??) from the database, caching when needed, so the lack of performance is
never noticed.

Mark Stuart



Richard Gaskin wrote:
> 
> Jan Schenkel wrote:
> 
>>> Now when large record sets are returned from a
>>> search, the UI (user
>>> interface) slows down, especially when resizing the
>>> stack to see more
>>> records in the table object. When resizing with no
>>> records, the UI is
>>> performs normally with fast resizing.
> ...
>> The problem is two-fold: it's a lot of data that has
>> to go through some pipe before it arrives in
>> Revolution, and Revolution then has to process and
>> format a lot of that to determine what to actually
>> display on screen, recalculate the size of the
>> scrollbar, etc.
> 
> FWIW, I did some subjective tests with scrolling large amounts of data 
> in Rev vs. Word, Excel, and others. Rev outperformed them all, quite 
> noticeably.
> 
> So if it seems slow, try the same size data anywhere else.  Sometimes a 
> lot of data just takes a long time to redraw.
> 
> Fortunately the user will likely resize a window infrequently.
> 
> -- 
>   Richard Gaskin
>   Managing Editor, revJournal
>   ___
>   Rev tips, tutorials and more: http://www.revJournal.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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15623495.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: UI performance and large data set in Table Object


Hi Jan,
Where the reading of the SQL data and loading into a table object is not
quite the issue here, never the less, it is an issue I haven't dealt with as
yet in this application.
But I will try your approach, copying your script to an archive for future
pondering.

This current issue is the resizing of the stack AFTER the data has loaded to
the table object.
When resizing, it is very slow and cumbersome and even produces delays to
the resized stack dimensions.

Mark Stuart


Jan Schenkel wrote:
> 
> --- mfstuart <[EMAIL PROTECTED]> wrote:
>> 
>> Hi All,
>> 
>> I have a question about large data sets (thousands
>> of lines) in a table
>> object and the slowing down of the UI performance,
>> especially on resizing
>> the stack.
>> 
>> My application interfaces to an MS SQL 2000 database
>> via ODBC. No problem
>> there.
>> The SQL table I have has over half a million records
>> in it, and this grows
>> all the time.
>> 
>> Potentially, the user could return all records,
>> which would take a while to
>> load them all.
>> But I've created the interface to allow the user to
>> return a smaller record
>> set. This can be alot of records - 10, 30, 40, 5
>> thousand or more, or
>> just a few hundred. It depends on how the user
>> searches the database.
>> 
>> Now when large record sets are returned from a
>> search, the UI (user
>> interface) slows down, especially when resizing the
>> stack to see more
>> records in the table object. When resizing with no
>> records, the UI is
>> performs normally with fast resizing.
>> 
>> Q: has any one seen this before? And if so, how do
>> you handle the drop in UI
>> performance?
>> 
>> Thanx,
>> Mark Stuart
>> 
> 
> Hi Mark,
> 
> The problem is two-fold: it's a lot of data that has
> to go through some pipe before it arrives in
> Revolution, and Revolution then has to process and
> format a lot of that to determine what to actually
> display on screen, recalculate the size of the
> scrollbar, etc.
> 
> For a project where it was taking a lot of time before
> the user saw anything, I decided to take a different
> approach: rather than rely on a single call to
> revdb_querylist()/revDataFromQuery(), to use a result
> set cursor and a 'send in time' construct to fetch 20
> records at a time.
> 
> This approach allows the user interface to remain
> responsive, and the user can see the table filling up
> as more data comes in. It also means you can cancel
> the rest of the data download as soon as the user
> finds the record he wants, or decides to make a
> different selection.
> 
> It looks something like this:
> 
> ##
> global gConnectionID
> local sFetchMsgID, sCursorID, sColumnCount
> 
> on mouseUp
>   CancelFetchTimer
>   put "SELECT * FROM Customers" into tQuery
>   put revdb_query(gConnectionID, tQuery) into
> sCursorID
>   if sCursorID is not a number then
> answer error sCursorID
> exit mouseUp
>   end if
>   put revDatabaseColumnCount(sCursorID) into
> sColumnCount
>   put empty into field "QueryResults"
>   send "FetchNext20Records" to me in 0 milliseconds
>   put the result into sFetchMsgID
> end mouseUp
> 
> on FetchNext20Records
>   put false into tStopFlag
>   repeat 20 times
> repeat with tColumn = 1 to sColumnCount
>   put revDatabaseColumnNumbered(sCursorID,
> tColumn) & \
>   tab after tNextPart
> end repeat
> put return into char -1 of tNextPart
> put revCurrentRecordIsLast(sCursorID) into
> tStopFlag
> if tStopFlag then
>   delete char -1 of tNextPart
>   exit repeat
> end if
>   end repeat
>   put tNextPart after field "QueryResults"
>   if tStopFlag then
> put empty into sFetchMsgID
>   else
> send "FetchNext20Records" to me in 100
> milliseconds
> put the result into sFetchMsgID
>   end if
> end FetchNext20Records
> 
> on CancelFetchTimer
>   if sFetchMsgID is not empty then
> cancel sFetchMsgID
> put empty into sFetchMsgID
>   end if
> end CancelFetchTimer
> ##
> 
> This is all off the top of my head, so beware of
> typos.
> 
> Hope this helped,
> 
> 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)
> 
> 
>  
> _

Re: UI performance and large data set in Table Object

2008-02-21 Thread Sarah Reichelt

On Fri, Feb 22, 2008 at 9:21 AM, mfstuart <[EMAIL PROTECTED]> wrote:
>
>  I haven't tried storing data in a custom property as yet, but wouldn't that
>  render the same lack of performance behavior, where putting the data into a
>  stack of the UI?

No, because the engine doesn't have to think about how to display your
data, it's just storing whatever you put in there.

I got involved in a project were data was being stored in fields on
another card, so not even visible. The amount of data was getting
quite large, about 40,000 lines in each field. When I changed it to
storing the data in custom properties, the speed of adding new data
points dropped from around 3 seconds to about 5 ticks!

Cheers,
Sarah
___
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: UI performance and large data set in Table Object


I haven't tried storing data in a custom property as yet, but wouldn't that
render the same lack of performance behavior, where putting the data into a
stack of the UI?

Mark Stuart


masmit wrote:
> 
> Mark, you might store the data from the database in a custom property  
> of the table field, and only show as much data as will fit in the  
> field at it's current size.
> 
> You'd have to write your own scrolling routines to update the  
> display, but it can be done.
> 
> Best,
> 
> Mark
> 
> On 21 Feb 2008, at 19:04, mfstuart wrote:
> 
>>
>> Hi All,
>>
>> I have a question about large data sets (thousands of lines) in a  
>> table
>> object and the slowing down of the UI performance, especially on  
>> resizing
>> the stack.
>>
>> My application interfaces to an MS SQL 2000 database via ODBC. No  
>> problem
>> there.
>> The SQL table I have has over half a million records in it, and  
>> this grows
>> all the time.
>>
>> Potentially, the user could return all records, which would take a  
>> while to
>> load them all.
>> But I've created the interface to allow the user to return a  
>> smaller record
>> set. This can be alot of records - 10, 30, 40, 5 thousand or  
>> more, or
>> just a few hundred. It depends on how the user searches the database.
>>
>> Now when large record sets are returned from a search, the UI (user
>> interface) slows down, especially when resizing the stack to see more
>> records in the table object. When resizing with no records, the UI is
>> performs normally with fast resizing.
>>
>> Q: has any one seen this before? And if so, how do you handle the  
>> drop in UI
>> performance?
>>
>> Thanx,
>> Mark Stuart
>> -- 
>> View this message in context: http://www.nabble.com/UI-performance- 
>> and-large-data-set-in-Table-Object-tp15618647p15618647.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
> 
> ___
> 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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15622814.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: UI performance and large data set in Table Object

2008-02-21 Thread Jan Schenkel

--- Richard Gaskin <[EMAIL PROTECTED]> wrote:
> Jan Schenkel wrote:
> 
> >> Now when large record sets are returned from a
> >> search, the UI (user
> >> interface) slows down, especially when resizing
> the
> >> stack to see more
> >> records in the table object. When resizing with
> no
> >> records, the UI is
> >> performs normally with fast resizing.
> ...
> > The problem is two-fold: it's a lot of data that
> has
> > to go through some pipe before it arrives in
> > Revolution, and Revolution then has to process and
> > format a lot of that to determine what to actually
> > display on screen, recalculate the size of the
> > scrollbar, etc.
> 
> FWIW, I did some subjective tests with scrolling
> large amounts of data 
> in Rev vs. Word, Excel, and others. Rev outperformed
> them all, quite 
> noticeably.
> 
> So if it seems slow, try the same size data anywhere
> else.  Sometimes a 
> lot of data just takes a long time to redraw.
> 
> Fortunately the user will likely resize a window
> infrequently.
> 
> -- 
>   Richard Gaskin
>   Managing Editor, revJournal
>  

Excellent point, Richard - Revolution is indeed much
faster than the MS behemoths. Combining Mark's advice
of caching the data in an off-screen buffer with the
'fake-threaded' chunked download approach, allows us
to squeeze every drop of performance out of our
favourite development tool...

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)

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
___
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: UI performance and large data set in Table Object

2008-02-21 Thread Richard Gaskin


Jan Schenkel wrote:


Now when large record sets are returned from a
search, the UI (user
interface) slows down, especially when resizing the
stack to see more
records in the table object. When resizing with no
records, the UI is
performs normally with fast resizing.

...

The problem is two-fold: it's a lot of data that has
to go through some pipe before it arrives in
Revolution, and Revolution then has to process and
format a lot of that to determine what to actually
display on screen, recalculate the size of the
scrollbar, etc.


FWIW, I did some subjective tests with scrolling large amounts of data 
in Rev vs. Word, Excel, and others. Rev outperformed them all, quite 
noticeably.


So if it seems slow, try the same size data anywhere else.  Sometimes a 
lot of data just takes a long time to redraw.


Fortunately the user will likely resize a window infrequently.

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.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: UI performance and large data set in Table Object

2008-02-21 Thread Jan Schenkel

--- mfstuart <[EMAIL PROTECTED]> wrote:
> 
> Hi All,
> 
> I have a question about large data sets (thousands
> of lines) in a table
> object and the slowing down of the UI performance,
> especially on resizing
> the stack.
> 
> My application interfaces to an MS SQL 2000 database
> via ODBC. No problem
> there.
> The SQL table I have has over half a million records
> in it, and this grows
> all the time.
> 
> Potentially, the user could return all records,
> which would take a while to
> load them all.
> But I've created the interface to allow the user to
> return a smaller record
> set. This can be alot of records - 10, 30, 40, 5
> thousand or more, or
> just a few hundred. It depends on how the user
> searches the database.
> 
> Now when large record sets are returned from a
> search, the UI (user
> interface) slows down, especially when resizing the
> stack to see more
> records in the table object. When resizing with no
> records, the UI is
> performs normally with fast resizing.
> 
> Q: has any one seen this before? And if so, how do
> you handle the drop in UI
> performance?
> 
> Thanx,
> Mark Stuart
> 

Hi Mark,

The problem is two-fold: it's a lot of data that has
to go through some pipe before it arrives in
Revolution, and Revolution then has to process and
format a lot of that to determine what to actually
display on screen, recalculate the size of the
scrollbar, etc.

For a project where it was taking a lot of time before
the user saw anything, I decided to take a different
approach: rather than rely on a single call to
revdb_querylist()/revDataFromQuery(), to use a result
set cursor and a 'send in time' construct to fetch 20
records at a time.

This approach allows the user interface to remain
responsive, and the user can see the table filling up
as more data comes in. It also means you can cancel
the rest of the data download as soon as the user
finds the record he wants, or decides to make a
different selection.

It looks something like this:

##
global gConnectionID
local sFetchMsgID, sCursorID, sColumnCount

on mouseUp
  CancelFetchTimer
  put "SELECT * FROM Customers" into tQuery
  put revdb_query(gConnectionID, tQuery) into
sCursorID
  if sCursorID is not a number then
answer error sCursorID
exit mouseUp
  end if
  put revDatabaseColumnCount(sCursorID) into
sColumnCount
  put empty into field "QueryResults"
  send "FetchNext20Records" to me in 0 milliseconds
  put the result into sFetchMsgID
end mouseUp

on FetchNext20Records
  put false into tStopFlag
  repeat 20 times
repeat with tColumn = 1 to sColumnCount
  put revDatabaseColumnNumbered(sCursorID,
tColumn) & \
  tab after tNextPart
end repeat
put return into char -1 of tNextPart
put revCurrentRecordIsLast(sCursorID) into
tStopFlag
if tStopFlag then
  delete char -1 of tNextPart
  exit repeat
end if
  end repeat
  put tNextPart after field "QueryResults"
  if tStopFlag then
put empty into sFetchMsgID
  else
send "FetchNext20Records" to me in 100
milliseconds
put the result into sFetchMsgID
  end if
end FetchNext20Records

on CancelFetchTimer
  if sFetchMsgID is not empty then
cancel sFetchMsgID
put empty into sFetchMsgID
  end if
end CancelFetchTimer
##

This is all off the top of my head, so beware of
typos.

Hope this helped,

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)

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
___
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: UI performance and large data set in Table Object

2008-02-21 Thread Mark Smith

Mark, you might store the data from the database in a custom property  
of the table field, and only show as much data as will fit in the  
field at it's current size.


You'd have to write your own scrolling routines to update the  
display, but it can be done.


Best,

Mark

On 21 Feb 2008, at 19:04, mfstuart wrote:



Hi All,

I have a question about large data sets (thousands of lines) in a  
table
object and the slowing down of the UI performance, especially on  
resizing

the stack.

My application interfaces to an MS SQL 2000 database via ODBC. No  
problem

there.
The SQL table I have has over half a million records in it, and  
this grows

all the time.

Potentially, the user could return all records, which would take a  
while to

load them all.
But I've created the interface to allow the user to return a  
smaller record
set. This can be alot of records - 10, 30, 40, 5 thousand or  
more, or

just a few hundred. It depends on how the user searches the database.

Now when large record sets are returned from a search, the UI (user
interface) slows down, especially when resizing the stack to see more
records in the table object. When resizing with no records, the UI is
performs normally with fast resizing.

Q: has any one seen this before? And if so, how do you handle the  
drop in UI

performance?

Thanx,
Mark Stuart
--
View this message in context: http://www.nabble.com/UI-performance- 
and-large-data-set-in-Table-Object-tp15618647p15618647.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


___
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

UI performance and large data set in Table Object