Export and Debug mode

I searched and not found anything specifically addressing this issue in the SD documentation, but I’m wondering if I need to turn off debugging and remove all log statements before producing an Application if I want to have an optimally sized, fastest running app.

Does leaving debugging turned on interfere with Notarizing?

What is best practice here?

Activating debugging does not impact the performance of exported scripts. All of Script Debugger’s debugging instrumentation is removed.

However, any logging taking place within your script remains. This does not to amount to too much overhead unless logging appears in high frequency loops or the logged expressions have high overheads or the volume of logged data is excessive.

If absolute performance is required then you’ll need to measure with/without your logging to determine if it’s presence is creating unacceptable overhead within your script.

1 Like

Thanks Mark
I’m starting to get the dreaded errOSAInternalTableOverflow so perhaps its time to ditch the logging statements. Some are in fact sitting inside relatively high frequency loops.

On that note I have some handlers with a large number of parameters (up to nine or so), many of which are common amongst the handlers. I’m inclined to bundle them up into arrays to reduce the clutter. Am I likely to reduce the object count that way?

This gets very difficult to determine. This kind of difference is probably fairly small and may push you back from the edge for a while but you’ll be back as soon as you add some new code. It all comes down to token counts and I suspect you are going to get a small benefit at the cost of making your code much harder to understand.

I know it’s a pain to make the change, but refactoring your handlers into a library and reducing your main script to its smallest size will set up for the future. The problem is that Script Debugger cannot debug into library scripts so you loose there too.