UmbrellaMan was replaced with a newer version that has a more sensible name some years ago (I still like to have fun with names but few know the old Glenn Miller song that was named after or why I'd choose it at all, and as I get older I try to keep in mind that other people have things do to beyond trying to sort their way through even more obscure names than the ones I eventually settle on, a lesson some Linux projects could learn from <g>) :
http://fourthworld.net/revnet/devolutio ... ivecode.gz
That version is unlocked and is maintained in LC v6.x, so it's compatible with LC Commercial, Enterprise, Indy, Business, and Community Editions from v5.5 through the present.
I never claim compatibility with any Developer Preview edition of LiveCode, because any build prior to Release Candidate is subject to changes which may affect a plugin. Still, I just ran Flight Recorder in LC 8.0 DP 11 and it seems to run well.
I should note that the profiling info shown in Flight Recorder's "MS" column (for "Milliseconds") are approximations made even less reliable by the method in which they're gathered. The main purpose of Flight Recorder is to trap messages in a way more tailorable than LiveCode's, with greater clarity than LiveCode's provided by the indenting which reflects the calling chain. The profiling was very much an afterthought, and even now not much of a priority for myself; I find that even the loose approximations it provides is more than enough for me to find opportunities for optimization.
All that said, the indenting alone will likely be as helpful as the profiling for finding bottlenecks, because redundant calls are easily identified but any non-redundant calls may take a seemingly large amount of time but you still won't know
why they're taking so much time, whether such calls are actually good candidates for optimization or just things that inherently take longer.
A few years ago I started sketching out another tool I was calling ScriptDoctor, which would analyze scripts and not only find things that take longer but also attempt to discern
why they're taking longer, and offer suggestions for optimization.
I've set that aside, however, mostly due to client projects keeping me so busy but also due to its limited utility: it would have a low ROI if positive at all, because:
a) the more time you spend with LiveCode the more you pick up habits that make your code more performant, so the value of the tool would only decrease over time;
b) some aspects of performance change between versions as features are added and refined, so a bottleneck identified through yesterday's rules may not apply tomorrow;
c) the best - and most enjoyable - way to optimize performance is to post code here for review and revision.
One of my favorite examples of c) is a wonderful discussion here titled "How to Speed Up This Code?":
http://forums.livecode.com/viewtopic.php?f=8&t=24945
A good read for a wide range of performance tips, and for seeing the benefits of getting lots of eyeballs on a problem. Many people contributed to that example, each bringing their own insights along the way, and ultimately a process that had taken 9 minutes was reduced to a few milliseconds.
In short, Chris, this is all just a long-winded way of saying that while profiling tools for LC are currently somewhat limited, the nature of such tools is always a bit limited anyway, so if you're in a position to post a portion of the code you're concerned about I'll bet we can explore it to boost its performance by perhaps as much as an order of magnitude or more. And along the way others will benefit from the discussion as well, and most importantly we'll have not only faster code, but an understanding of
why it's faster.