Re: Optimize your script with Shark
Re: Optimize your script with Shark
- Subject: Re: Optimize your script with Shark
- From: has <email@hidden>
- Date: Tue, 18 Oct 2005 17:17:05 +0100
Daniel Jalkut 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.
>
>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?
The mailing list archives provide permanent links if you need 'em <http://lists.apple.com/archives/applescript-users/2005//Oct/index.html>, and you're welcome to quote away, of course.
>>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.
I have considered the possibility of writing a custom OSA shell that automatically 1. measures the time spent on osax/application calls (trivial to do if you know OSA programming; see OSASetSendProc), and 2. measures the time spent in the top-level handlers of your main script (by mucking about with OSAGetHandler and OSASetHandler to wrap the script's original handlers inside custom handlers that trigger the appropriate timers before and after calling the original). The downsides are that #1 won't help in application contexts that don't let you select the OSA component to use, and #2 won't help in more complex scripts that use libraries and OOP so its usefulness is limited. Still, a set of code munging macro scripts and maybe a thin OSA wrapper that just does the AE timings might make a practical compromise.
>In any case, you've got me thinking that it's worth a bug report to Apple requesting sample-able AppleScript code.
What you need is a profiling tool that hooks into the AS interpreter, either as an AS-specific extension or via an addition to the OSA API. By all means file a feature request on it, though I have to be honest and say that with all the much more serious bugs and deficiencies in AS and related technologies I doubt it'll have very high priority at Apple. You may be better asking Mark Aldritt, who knows a thing or two about doing deep AS/OSA ju-ju and might even know where to poke.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
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