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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
