Rev performance: help! (solved)

[Dave Cragg]

On 7 Dec 2005, at 15:23, Jon Seymour wrote:

> Thanks again to Dave for insisting that I must have had a libURL  
> call in there somewhere :)

Although we solved Jon's immediate problem (wrong url), I think there  
must have been something else going on to produce the results he  
originally reported.

One possible suspect was the use of a "wait ... with messages"  
statement while a url was still loading. Although we never confirmed  
this, it's probably worth mentioning this potential gotcha. (Brought  
to my attention recently by Chipp Walters.)

libUrl uses the "wait for messages" statement to implement it's  
asynchronous behavior, in a "wait" loop something like this:

    repeat until <some condition>
       wait for messages
    end repeat

This is equivalent to:

   wait until <some condition> with messages

If you later use another "wait ... with messages" statement while the  
earlier one is still "waiting", the earlier "wait" will remain stuck  
while the later one is waiting, even if its condition has been met.  
The following script illustrates this, where handler_one won't  
complete until handler_two completes.

global gDone

on mouseUp
   put false into gDone
   send handler_two to me in 10 milliseconds
   handler_one
end mouseUp

on handler_one
   wait until gDone = true with messages
   put "handler_one finished" & cr after field 1
end handler_one


on handler_two
   put "handler_two stage 1" & cr after field 1
   put true into gDone
   repeat 3
     wait 2 seconds with messages
    put "handler_two stage 2" & cr after field 1
   end repeat
end handler_two


The upshot of this is that if you use load, then have a wait  
statement like this:

   load url myUrl
   wait unitl <some condition> with messages

the "load url" won't complete until <some condiion> is met. If <some  
condition> takes a long time to be satisfied, the "load" will take  
that long as well.

This is a potential problem with "black box" scripted libraries such  
as libUrl which are implementing asynchronous behavior.

You can use the waitDepth function to see if there are any  
outstanding waits. But avoid the temptation to do something like  
"wait until the waitdepth is 1 with messages", which immediately  
causes the problem. Be careful! (But not too careful. :-))

Judy, if you're reading, I wonder if this kind of thing may have had  
something to do with what you were seeing.

Cheers
Dave