You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2002/02/12 15:43:08 UTC
Profiler interfaces in scratchpad
Hi All,
Hope all is well.
Just been looking through the Profiling interfaces in
scratchpad which look quite nice. I've come up with a couple of
questions though:
1. What should the intended calling order for the Profiler class be ?
ie:
// create profiler
Profile p = new Profiler();
...
// add profilables
p.add(myProfilable1);
p.add(myProfilable2);
...
p.add(myProfilableN);
// add report
p.report(new CSVProfileReport("report.csv"));
// start reporting (reporting runs in a separate thread)
p.start();
...
p.stop();
Should there be a start()/stop() method in the Profiler interface, or
left up to the implementation ?
2. Each Profilable object needs some sort of identifying name - Profiler.add()
actually documents a named argument which seems to have been removed.
Should there be a Profilable.getProfilableName(); method or something similar
added to Profilable's interface ?
3. ProfileReport.addGroup() has me confused.
What is the concept of a 'group' here ? Do the groupName and subgroupName
parameters represent the Profilable object name, and the names of its
Profilable points ?
Or the name of the Profilable object and it's children Profilables ? (in which
case where are the profilable points printed ?).
Or something else entirely ?
What if it was:
void addProfilable(Profilable profilable);
An implementation could then get the name of the profilable object,
along with its profiling points and child profilables if any ?
Any thoughts/comments would be much appreciated ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Profiler interfaces in scratchpad
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
> On Tue, Feb 12, 2002 at 06:32:40PM +0100, Marcus Crafter wrote:
>
>>On Tue, Feb 12, 2002 at 11:47:38AM -0500, Berin Loritsch wrote:
>>
>>>Marcus Crafter wrote:
>>>
>> Ok. If what I've said above is right, I reckon I get it now. :)
>>
>
> I've got a few spare evenings now. I'll see if I can come up with an
> implementation.
Awesome!
Its been on the backburner for a bit now...
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Profiler interfaces in scratchpad
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Tue, Feb 12, 2002 at 06:32:40PM +0100, Marcus Crafter wrote:
> On Tue, Feb 12, 2002 at 11:47:38AM -0500, Berin Loritsch wrote:
> > Marcus Crafter wrote:
>
> Ok. If what I've said above is right, I reckon I get it now. :)
I've got a few spare evenings now. I'll see if I can come up with an
implementation.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Profiler interfaces in scratchpad
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Tue, Feb 12, 2002 at 11:47:38AM -0500, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >>
> >
> > I would find it better in the interface - at least then it's a
> > defined entry point into the profiler, and all implementations will
> > use the same terminology.
>
> We can make the Profiler extend the Startable interface to get it.
ok. Sounds good to me.
> > Might getName() conflict with other classes that could contain such a
> > generic method name ? How about getProfilableName() or something
> > else indicating it's use in profiling and that won't conflict
> > another interface, eg. Router.getName() or Customer.getName(), or
> > OperatingSystem.getName(), etc ?
>
> It is considered bad practice for a Component to have a getName(), but I do
> see your point. Can I ask you this: Would it be reasonable to record the
> Customer name/Router name as the name in the ProfileReport? I think so.
> That saves the implementor from writing a new method.
I don't know. I'm not so convinced :) It could be that we're not
actually in charge of what string getName() returns, and whether it's
appropriate as the name for the profile report.
And what if some poor class has a getName() method that doesn't even
return a String but a char[], or a Name object or something even
more esoteric ? Then it won't even compile :(
> > Ok, I understand so far (I think :) ), but how do the profilable
> > point
> > names get listed. addGroup() can't read them, and there
> > doesn't seem to be any other method in ProfileReport to be able
> > to specify them (or access from within the report
> > via ProfilePoint.getName() ) ?
>
> The Profiler sets the names in the addGroup() stage. Remember, the groups
> are set up in advance, and the ProfileReport remembers those values when
> rendering the report.
Ok, this is the part I found confusing. So addGroup() is used to
set both the children profilable names, *and* the profile point
names. The diagram:
"Cocoon Container" Is the group name
|
+----------+-----------+
| | |
Cache" "ECM" "Sitemap" Are the sub groups names
| | |
misses" "requests" "500 Errors" Are the profilable point names
Would then actually be:
report.addGroup("Cocoon Container", { "Cache", "ECM", "Sitemap" });
report.addGroup("Cache", { "misses" });
report.addGroup("ECM", { "requests" });
report.addGroup("Sitemap", { "500 Errors" });
Following an in-order traversal.
And it's up to the reporting engine to differentiate between subgroup
names and profilepoint names when organising and printing sample data.
Ok. If what I've said above is right, I reckon I get it now. :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Profiler interfaces in scratchpad
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
> Hi Berin,
>
> Thanks for your answers, much appreciated.
>
> On Tue, Feb 12, 2002 at 10:13:58AM -0500, Berin Loritsch wrote:
>
>>Marcus Crafter wrote:
>>
>>> Should there be a start()/stop() method in the Profiler interface, or
>>> left up to the implementation ?
>>>
>>Good point, which would be more natural to you?
>>
>
> I would find it better in the interface - at least then it's a
> defined entry point into the profiler, and all implementations will
> use the same terminology.
We can make the Profiler extend the Startable interface to get it.
>>You are correct. A getName() method has been added ot Profilable.
>>
>
> Great. Thanks.
>
> Might getName() conflict with other classes that could contain such a
> generic method name ? How about getProfilableName() or something
> else indicating it's use in profiling and that won't conflict
> another interface, eg. Router.getName() or Customer.getName(), or
> OperatingSystem.getName(), etc ?
It is considered bad practice for a Component to have a getName(), but I do
see your point. Can I ask you this: Would it be reasonable to record the
Customer name/Router name as the name in the ProfileReport? I think so.
That saves the implementor from writing a new method.
>>The Group concept is a way to group the profile points together and
>>dynamically
>>create nicely scoped names. The group concept works to allow a GUI
>>ProfileReport
>>to present a nice tree view, or for Textual ProfileReports to create scoped
>>names to give the values some meaning.
>>
>>The latter statement you had is correct. The Profilable object can have
>>child
>>Profilable objects. I thought I had a nice graphic in there that shows how
>>it is supposed to work together.
>>
>
> The graphic is nice, but the letters G1, C1, C2, etc to me
> didn't mean anything in particular (ie. I didn't know whether
> they mean't profilable or profilable point ?). :)
Ok. The "node" or end is always the ProfilePoint. The graphic is to
show the order of group calls. All Groups/SubGroups are declared before
actual ProfilePoints are sampled.
>
> So your example:
>
> "Cocoon Container" Is the group name
> |
> +----------+-----------+
> | | |
> "Cache" "ECM" "Sitemap" Are the sub groups names
> | | |
> "misses" "requests" "500 Errors" Are the profilable point names
>
> and this would be built up like:
>
> report.addGroup("Cocoon Container", { "Cache", "ECM", "Sitemap" });
>
> (dynamically of course) ??
Yep.
> Ok, I understand so far (I think :) ), but how do the profilable point
> names get listed. addGroup() can't read them, and there
> doesn't seem to be any other method in ProfileReport to be able
> to specify them (or access from within the report
> via ProfilePoint.getName() ) ?
The Profiler sets the names in the addGroup() stage. Remember, the groups are
set up in advance, and the ProfileReport remembers those values when rendering
the report.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Profiler interfaces in scratchpad
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Berin,
Thanks for your answers, much appreciated.
On Tue, Feb 12, 2002 at 10:13:58AM -0500, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >
> > Should there be a start()/stop() method in the Profiler interface, or
> > left up to the implementation ?
>
> Good point, which would be more natural to you?
I would find it better in the interface - at least then it's a
defined entry point into the profiler, and all implementations will
use the same terminology.
> >2. Each Profilable object needs some sort of identifying name -
> >Profiler.add()
> >actually documents a named argument which seems to have been removed.
> >
> >Should there be a Profilable.getProfilableName(); method or something
> >similar
> >added to Profilable's interface ?
>
> You are correct. A getName() method has been added ot Profilable.
Great. Thanks.
Might getName() conflict with other classes that could contain such a
generic method name ? How about getProfilableName() or something
else indicating it's use in profiling and that won't conflict
another interface, eg. Router.getName() or Customer.getName(), or
OperatingSystem.getName(), etc ?
> The Group concept is a way to group the profile points together and
> dynamically
> create nicely scoped names. The group concept works to allow a GUI
> ProfileReport
> to present a nice tree view, or for Textual ProfileReports to create scoped
> names to give the values some meaning.
>
> The latter statement you had is correct. The Profilable object can have
> child
> Profilable objects. I thought I had a nice graphic in there that shows how
> it is supposed to work together.
The graphic is nice, but the letters G1, C1, C2, etc to me
didn't mean anything in particular (ie. I didn't know whether
they mean't profilable or profilable point ?). :)
So your example:
"Cocoon Container" Is the group name
|
+----------+-----------+
| | |
"Cache" "ECM" "Sitemap" Are the sub groups names
| | |
"misses" "requests" "500 Errors" Are the profilable point names
and this would be built up like:
report.addGroup("Cocoon Container", { "Cache", "ECM", "Sitemap" });
(dynamically of course) ??
> A Textual ProfileReport would render the ProfilePoints (listed lastly) like
> this:
>
> "Cocoon Container->Cache: misses"
> "Cocoon Container->ECM: requests"
> "Cocoon Container->Sitemap: 500 Errors"
>
> (Or something similar)
Ok, I understand so far (I think :) ), but how do the profilable point
names get listed. addGroup() can't read them, and there
doesn't seem to be any other method in ProfileReport to be able
to specify them (or access from within the report
via ProfilePoint.getName() ) ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Profiler interfaces in scratchpad
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
> Hi All,
>
> Hope all is well.
>
> Just been looking through the Profiling interfaces in
> scratchpad which look quite nice. I've come up with a couple of
> questions though:
>
> 1. What should the intended calling order for the Profiler class be ?
>
> ie:
>
> // create profiler
> Profile p = new Profiler();
> ...
>
> // add profilables
> p.add(myProfilable1);
> p.add(myProfilable2);
> ...
> p.add(myProfilableN);
>
> // add report
> p.report(new CSVProfileReport("report.csv"));
>
> // start reporting (reporting runs in a separate thread)
> p.start();
> ...
> p.stop();
>
> Should there be a start()/stop() method in the Profiler interface, or
> left up to the implementation ?
Good point, which would be more natural to you?
> 2. Each Profilable object needs some sort of identifying name - Profiler.add()
> actually documents a named argument which seems to have been removed.
>
> Should there be a Profilable.getProfilableName(); method or something similar
> added to Profilable's interface ?
You are correct. A getName() method has been added ot Profilable.
> 3. ProfileReport.addGroup() has me confused.
>
> What is the concept of a 'group' here ? Do the groupName and subgroupName
> parameters represent the Profilable object name, and the names of its
> Profilable points ?
>
> Or the name of the Profilable object and it's children Profilables ? (in which
> case where are the profilable points printed ?).
The Group concept is a way to group the profile points together and dynamically
create nicely scoped names. The group concept works to allow a GUI ProfileReport
to present a nice tree view, or for Textual ProfileReports to create scoped names
to give the values some meaning.
The latter statement you had is correct. The Profilable object can have child
Profilable objects. I thought I had a nice graphic in there that shows how it is
supposed to work together.
"Cocoon Container"
|
+----------+-----------+
| | |
"Cache" "ECM" "Sitemap"
| | |
"misses" "requests" "500 Errors"
A Textual ProfileReport would render the ProfilePoints (listed lastly) like this:
"Cocoon Container->Cache: misses"
"Cocoon Container->ECM: requests"
"Cocoon Container->Sitemap: 500 Errors"
(Or something similar)
> What if it was:
>
> void addProfilable(Profilable profilable);
>
> An implementation could then get the name of the profilable object,
> along with its profiling points and child profilables if any ?
>
> Any thoughts/comments would be much appreciated ?
>
> Cheers,
>
> Marcus
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>