If I wanted to profile my application I would use a profiler. However,
Logging can be used for profiling but is just one of various use-cases
and its not a important one. If you wish I could list the others, but in
short:
Basically its three things I _want_ to change:
1) Doing what logging does, just more _granular_. Granulate to methods
or files.
2) Doing what logging does, just with _less coding_ for the _user_.
Granulate without currently needed boilerplate code.
3) Doing what logging does, just more _verbose_. Show where the
particular log statements have been originating from.
The granularity is important if someone has long files, I am thinking of
the UIComponent example right now.
The verbosity (line number and location) is very important for bug
tracking or code functionality understanding.
The simplicity is very important for developers who dislike to write a
lot of boilerplate code.
I, as well as others, have tried to implement it with currently
available features but those three problems still exist. A solution to
all this would be the mentioned approach of compile-time-data-injection.
yours
Martin.
On 20/01/2012 06:53, Roland Zwaga wrote:
I'm still looking for the use case. Do you just want release player
performance profiling?
I believe there is a bit of cognitive dissonance here, I see Martin talking
about logging and a lot
of people chiming in about profiling, clearly these two things are
different beasts.
Sure, logging can be used for profiling, but that's just one use case for
logging.
A release version of an application can still contain logging, not all
logging uses trace() as its
target as you all might know. Having solid logging in your application is
important in the case
of application errors or perhaps even usage statistics etc.
Martin, am I wording this right?
cheers,
Roland
