Profiler: Any Interest?

Corona Classifieds Other Products and Services
#1

I’m in the process of building a really cool profiler called “Clicktock” for Corona (and technically Lua in general). It logs time taken for functions in a special way that makes you able to run your app at normal (or very close to normal) speeds with minimal framerate stuttering. Then, it takes all the information in real-time and builds a list of stats for the amount of time each function has taken to run. The list can be sorted by number of calls to a function, average time, total time, or percent of program time. So far, it’s moderately simple (only function calls and Lua file first run times), but it has the potential to get far more powerful and capable. When you use Clicktock, it adds a little button to the corner of your app that brings out the sliding drawer of statistics.

Screenshots of the drawer opened and closed on the Dusk example app:

The drawer acts as an overlay on the app, so you can actually profile your application on-device.

So, to recap:

Pros

  • Node.JS and Lua

  • Runs with zero slowdown of your app (potentially a bit, but I’ve never experienced any)

  • Allows you to profile your app on-device

Cons

  • A little simplistic right now

  • …That’s all I can think of

Is there any interest for this kind of tool? I’ve found it pretty useful for profiling Crystalline; it was able to keep everything running at perfect speed but pinpoint the sections in my code that were taking the longest.

After releasing Dusk, CBEffects, and several other open-source tools, I’m thinking of making this one paid, to see how things go. It won’t be expensive, though, so don’t worry :). Hopefully, the forum software will put my price poll in here, so please vote on it. Thanks!

  • Caleb
#2

via debug.sethook?  are you also tracking individual lines (in addition to calls) by depth?  and do the sum of the internal line times equal the overall time of the call?  (that is, sum of any lower depth = sum of next higher depth, properly reporting any “lost time” system overhead)  so that you could potentially “drill into” a call for a problem line, which is doing a call, which you could drill into, etc…?

if you’re doing all that, then you’ve got relatively more value-added, much of which might be in how well you present the results (the ui), which if done well i think you could easily charge $10 or more for it, which would be appropriate as you’ll (probably?) only have a small audience of more serious developers interested in “detailed profiling”.

otoh, if you’re not doing quite that much, perhaps it’s just sort of an “overview” of top-level call timings, then it still has value, but maybe a different audience and price point, maybe a couple bucks (ish?) but potentially a wider audience of more casual developers just needing “a little” profiling help.  (which they could maybe DIY if they rtfm of sethook, but you’re saving them that trouble, so that instead is where your value-added comes from, so priced accordingly)

fwiw, hth, $.02

#3

That looks like an awesome tool. Performance can be really difficult to debug and fix, so would definitely come in handy. From my point of view, if I was stuck with an app that was too slow, I definitely wouldn’t mind paying for a profiler.

Make sure you pick a payment method that’s easy to use and widespread. Also, bear in mind that people change their expectations when they’ve paid for a product – they will expect things like tech support and refunds, which being one person it can be pretty tough to handle – especially if you’re lucky and get a lot of customers.

There are a few people out there who have attempted to sell such tools, but I’m not sure what kind of success they’ve had. Hope someone here has experience they are willing to share.

On the technical side, I suppose this would only be able to measure performance issues in Lua – so “external” performance culprits like physics and audio wouldn’t be included? How do you handle things that trigger very often, like transitions, enterFrame handlers and such?

I suppose an alternative business model would be to sell this to someone who makes Lua IDEs.

#4

Thanks for your feedback!

I’m not even touching the debug library right now. That’s actually one of the reasons it runs so quickly - I only collect the information I need, so Lua doesn’t have to run a function for every last line of the script. That might be something that comes if it gets more advanced; right now, it’s quite simple - it gives a very high-level overview of what function calls are taking longest. It’s not even close to complete, either. The mechanisms I use to measure time have only been barely tapped into (the actual technique is still secret B), though I’m sure if you think about it long enough you’ll figure it out. No guessing, though, please!). Instead of using a “dumb” profiler that times every single line, with my approach, I can time specific lines for maximum speed and accuracy; i.e. instead of profiling every line from 1 to 10,000, I can only filter the profiler to only lines which would likely be taking time, and thus keep things running at full speed. Or time the whole function and subtract the time each Corona function call line took to run to get your “real” program time.

Potentially, I could sell the current one (once it’s feature-complete) as the “simple” or “lightweight” version for $3-5, then add far more features (again, I haven’t even touched the debug library!) and up the price like @davebollinger says for the “deeper” programmers.

The profiler right now can only measure Lua code time. But, as I said a couple of paragraphs above this, I could potentially subtract the time for Corona calls to get the real time, or subtract the time for your own code to get the Corona time. As for enterFrame handlers, if they’re Lua code that you have access to, they’ll be timed. So that’s that.

Anyhoo and anyhow, thanks so much for both of your feedback. I greatly appreciate it.

  • Caleb
#5

via debug.sethook?  are you also tracking individual lines (in addition to calls) by depth?  and do the sum of the internal line times equal the overall time of the call?  (that is, sum of any lower depth = sum of next higher depth, properly reporting any “lost time” system overhead)  so that you could potentially “drill into” a call for a problem line, which is doing a call, which you could drill into, etc…?

if you’re doing all that, then you’ve got relatively more value-added, much of which might be in how well you present the results (the ui), which if done well i think you could easily charge $10 or more for it, which would be appropriate as you’ll (probably?) only have a small audience of more serious developers interested in “detailed profiling”.

otoh, if you’re not doing quite that much, perhaps it’s just sort of an “overview” of top-level call timings, then it still has value, but maybe a different audience and price point, maybe a couple bucks (ish?) but potentially a wider audience of more casual developers just needing “a little” profiling help.  (which they could maybe DIY if they rtfm of sethook, but you’re saving them that trouble, so that instead is where your value-added comes from, so priced accordingly)

fwiw, hth, $.02

#6

That looks like an awesome tool. Performance can be really difficult to debug and fix, so would definitely come in handy. From my point of view, if I was stuck with an app that was too slow, I definitely wouldn’t mind paying for a profiler.

Make sure you pick a payment method that’s easy to use and widespread. Also, bear in mind that people change their expectations when they’ve paid for a product – they will expect things like tech support and refunds, which being one person it can be pretty tough to handle – especially if you’re lucky and get a lot of customers.

There are a few people out there who have attempted to sell such tools, but I’m not sure what kind of success they’ve had. Hope someone here has experience they are willing to share.

On the technical side, I suppose this would only be able to measure performance issues in Lua – so “external” performance culprits like physics and audio wouldn’t be included? How do you handle things that trigger very often, like transitions, enterFrame handlers and such?

I suppose an alternative business model would be to sell this to someone who makes Lua IDEs.

#7

Thanks for your feedback!

I’m not even touching the debug library right now. That’s actually one of the reasons it runs so quickly - I only collect the information I need, so Lua doesn’t have to run a function for every last line of the script. That might be something that comes if it gets more advanced; right now, it’s quite simple - it gives a very high-level overview of what function calls are taking longest. It’s not even close to complete, either. The mechanisms I use to measure time have only been barely tapped into (the actual technique is still secret B), though I’m sure if you think about it long enough you’ll figure it out. No guessing, though, please!). Instead of using a “dumb” profiler that times every single line, with my approach, I can time specific lines for maximum speed and accuracy; i.e. instead of profiling every line from 1 to 10,000, I can only filter the profiler to only lines which would likely be taking time, and thus keep things running at full speed. Or time the whole function and subtract the time each Corona function call line took to run to get your “real” program time.

Potentially, I could sell the current one (once it’s feature-complete) as the “simple” or “lightweight” version for $3-5, then add far more features (again, I haven’t even touched the debug library!) and up the price like @davebollinger says for the “deeper” programmers.

The profiler right now can only measure Lua code time. But, as I said a couple of paragraphs above this, I could potentially subtract the time for Corona calls to get the real time, or subtract the time for your own code to get the Corona time. As for enterFrame handlers, if they’re Lua code that you have access to, they’ll be timed. So that’s that.

Anyhoo and anyhow, thanks so much for both of your feedback. I greatly appreciate it.

  • Caleb