Re: Optimize your script with Shark
Re: Optimize your script with Shark
- Subject: Re: Optimize your script with Shark
- From: Daniel Jalkut <email@hidden>
- Date: Tue, 18 Oct 2005 10:26:53 -0400
On Oct 18, 2005, at 6:29 AM, has wrote: The point of a profiler is to tell you quickly and easily (i.e. at a glance) which portions of your script you need to optimise. If it tells you that system API X is causing the problem, but you have to go through your AS code manually trying to figure out which parts of it (there may be many) are very indirectly invoking that API, it's neither quick nor easy; therefore you haven't really gained anything from using it.
You might be right that it's inappropriate to call this a "profiling" solution. I didn't think much (obviously) about the shortcomings of the approach before I wrote about it. I would like to add an addendum highlighting some of the points you've made. Can I reference you by name and/or link? FWIW, I did try some practical tests today and still don't see any value in it. I share your frustration at the lack of advanced developer tools, but I don't think you've found the holy grail just yet. Shark may provide a wealth of information, but it's the wrong sort of information for ASers. ASers want to know how long [in relative terms] is being spent calling each local and application handler (and, if they're being really obsessively granular, on each line of code). Shark is useless for this, and anything else it produces is just das blinkenlights: impressive to watch, but doesn't tell you what you need to know.
A very interesting proposal. I have higher confidence that I'd be able to trace back to the offending script code, but I have pretty lightweight scripts so I may not have good representative test cases. Still, here's a suggestion: what might be useful is a collection of macro-style scripts for SE/Smile/SD that can scan through [a copy of] the user's script, inserting timer triggering code into each handler, then run it and collate the results. It'd really need a custom osax to keep track of all the timing data for efficiency's sake, but that wouldn't be too hard to write. A crude solution, and won't provide quite as much information as they'd really like (i.e.. how long is being spent in osax and application calls; you'd need something like a custom OSA shell or evil code injection hacks to extract that info). But at least it'd show how long the script spends in each local handler, which is still the single most useful piece of information for a scripter to have. Might make a nice project for someone interested in this stuff... ;)
An interesting idea. I wonder if somebody with a bit of OSA-hacking could somehow convince the scripting system itself to do this. Instead of starting/stopping the profiler in the crude way I outlined in my blog, it would be cool to announce the symbolic script location in a way that Shark would pick up on.
In any case, you've got me thinking that it's worth a bug report to Apple requesting sample-able AppleScript code.
Daniel
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden