Hi All,
Hope all is well.
Over the weekend I spent some time playing around with the
Profiler interfaces in scratchpad. I've come up with an initial
version of the code, but during implementation it got me
thinking about future ideas.
I had a couple of thoughts, and I'd be interested in any comments, as
they require changes to the current API.
Bear with me, hopefully this is clear :)
The current API has the Profiler class in control. It does the
sampling, and pushes out the data to the reporting implementation.
This model has some disadvantages:
1. Data is pushed out to the reporting engine, which means we can't
write any on-demand reporting classes (eg. UpdatableSwingProfileReport,
ServletProfileReport, etc). :(
2. If we enhance Profiler to support multiple reports, all reports
will receive sample data at the same time interval. :(
3. For large scale applications where sampling time is not negligable,
samples and the timestamp value can be inaccurate when printed. :(
4. The reporting object must be initialized with the profilable object
names and profile point names before any sampling takes place so
it knows how to label information.
This means it requires some voodoo code to dynamically add
Profilables to the system without restarting the Profiler. :(
On an implementation level, it means the reporting engine must
maintain a second (internal) copy/reference of each Profilable's
names and their profile points names (the first copies are in the
Profilable objects themselves), and maintain relationship hierarchies
between any child profilable objects.
(I found this to be a real mess to implement as ProfileReport.addGroup()
does not distinguish between profile point names and profilable object
names)
We can remove all these limitations and reduce implementation
complexity by changing the way sampling takes place.
Instead of implementing a push model where the profiler samples
data and pushes it out to the reporting implementation, we could
consider a pull model, where the reporting implementation does
the sampling directly.
This fixes all of the above listed disadvantages, and also
makes implementation much easier.
At the interface level, we would have to change ProfileReport to be
something like:
interface ProfileReport
{
void startReport();
void endReport();
void addProfilable( Profilable profilable );
void sample();
}
Where 'startReport' would signal the reporting engine it can
being sampling.
Since the reporting class does the sampling, it can be made
configurable with sampling times (and/or support on-demand
sampling), etc.
Since it maintains references directly to each profilable, supporting
dynamic's is easy, and the report also doesn't need to maintain any
group/subgroup names/references.
Also, since sampling is done by the reporting class when the
data is needed it's more likely to be accurate in large scale
environments.
To support multiple reports we'd need to change Profiler so it
had:
interface Profiler
{
void addReport( ProfileReport report );
}
Instead of just 'report(...)', and perhaps consider some
'remove' methods.
Hopefully that's understandable, please feel free to ask any
questions.
Thoughts, comments ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
