100% CPU on simple repeat loop

I just noticed something. I finally hooked up my ASOC app and ran it. The CPU jumped to 100% in about a second. The old ASS APP uses about 1.5% when running the same script basically, on the same machine. It runs rsync in the background at about 20% CPU with nothing else big going on and the app itself is showing 100%…

So I did a test with a new app with one window, a button hooked up to a simple repeat loop:

repeat 100 times
delay 1
end repeat

And bingo… 100% CPU steady on

Any one else notice this? Should this be a concern?

Rob

Interesting – delay used to have that problem in ordinary applets. I guess the answer is to use an NSTimer, or even:

do shell script "sleep 1"

Yes, It appears delay is problematic in ASOC. No matter how I use it - my app runs at 100% till it quits!

in ASS apps it is no problem. Also in an applet it works fine. What would be causing this in ASOC?

Hope they fix that. How does one report a bug? I never have done that.

both

performSelector_withObject_afterDelay_

and

do shell script “sleep 1”

work fine

Cheers, Rob

Hi,

using delays for repetitive tasks is always bad programming habit, because a single-threaded environment like AppleScript Studio is locked up.

In ASS it’s better to use the idle handler, in ASOC NSTimer or performSelector_withObject_afterDelay_

First you register as a developer, then you go to www.bugreporter.com.

Yes that is ideal. it is a bit tricky though for my current setup. This is just a schematic example and not the actual code:

on processfiles_opt1_opt2_opt3_(filelist,val1,val2,val3,) --many more options than this

repeat with the theFile in filelist

set pid to do shell script "rsync options theFile theDestination > output file" etc...

repeat while pid is in process list 
update progress via output file data
delay 1   --here it is  so I need to outsource the delay to an NStimer
end
end repeat

--finish up work here is necessary

end processfiles_opt1_opt2_opt3_

the traditional way to do these kind of loops is to hold up the flow while checking to see if the process, in this case rsync in background, is done and then finish the routine. To use an NStimer I will need to break up the repeat loop into handlers to process the files then create the timer which checks the rsync progress and then when rsync finishes, go through the process loop again for the other files or call the finish up handler. not such a bad idea but I have 20+ options to pass to the process loop and I will have to pass them somehow on down the line through these handlers, or create a ton of properties.

I am trying to figure out a way to simulate the delay/update progress loop within the big loop via

performSelector:withObject:afterDelay:

or maybe even

performSelectorOnMainThread:withObject:waitUntilDone:

I think NSTimer may in the end be the best but requires serious restructuring of the loop that worked very well in ASS.

Any ideas gratefully accepted.

Rob

Instead of doing "do shell script " you might consider NSTask. During an NSTask you can set an NSNotification to inform you when changes occur. This will not lock up the UI and makes for a more elegant solution.

Just a thought. :slight_smile:

Thanks Craig,

I tried NSTask years ago in this app but that was ASS and there were problems using it as a call method. So now I am intrigued. I’ll check it out. Let me know if you have any pointers to NSTask info other than the usual Docs. Are you still planning on the MVC video?

Rob

Look at this post.

http://macosx.com/forums/software-programming-web-scripting/4522-better-way-read-nstask.html

One thing that’s possibly not clear from that post is that NSFileHandleReadCompletionNotification is sent every time the task returns some text. So that’s going to be useful to Rob, but he’ll probably also want to add an observer for the task’s NSTaskDidTerminateNotification, so he’ll be notified when it’s finished.

I’m grooving on the possibilities with NSTask. That is my next project.

In the mean time I went ahead and broke up my script using NSTimer to cycle the progress and report back. Guess what?
The cancel button works perfectly. The UI is responsive and even the menulet is completely accessible and responsive during a heavy run. Awesome! The old delay loop in ASS was always a limiting factor for my app. Now it feels more OBJ-c. It has been a haul but ASOC is looking better all the time. I love the way you can just do all the OBJ-c relatively directly.

Thanks Craig, Shane, Stefan,

Rob