Spike - Logging consolidation - Do our trace decorators bring any value?

[kimadeline]

From the #9611 spike for #8527

See if the decorators have value wherever they are used or if we can replace them with the exported trace functions, and revisit/dev design the useful ones (did I just create a spike from a spike).

[karrtikr]

The only decorator which seems to be useful is @traceDecorators.error. To use traceError you've to explicitly put the try..catch block around it, whereas having a decorator makes it much easier to maintain.

@traceDecorators.verbose() is the major culprit in spamming the Developer console as it also prints the return value object, arguments, and time taken to execute the method.
The time taken to execute the method can be of little use. For eg. to figure out if fetching conda interpreters takes most of the time. But we use CPU profiles to figure those out.

So IMO we should be getting rid of all instances of @traceDecorators.verbose/info/warn().

For the traces provided by @traceDecorators.verbose that could be useful, IMO we should keep using the decorators.

We can decide which traces are useful when reviewing the PR, which will include the DS team.

[DonJayamanne]

we should be getting rid of @traceDecorators.verbose/info/warn()

I don't think we should remove all. We (DS team) use a lot of these trace messages when diagnosing bugs & perf related issues.
We check what interpreters have been found, discovered, whether ds server has started, etc.

Rich Chiodo (@rchiodo) /cc

[DonJayamanne]

For eg. to figure out if fetching conda interpreters takes most of the time during activation

Not sure this is true. Extension loads even if conda interpreters takes a long time to load.
Karthik Nadig (@karthiknadig) I think we had a chat about this. Finding interpreters is a background task, E.g. extension loads in < 180ms for me, finding conda envs takes ~ 1 second for me on a Mac.