Re: profiler implementation

[Daniel Kraft]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi John and all,

On 08/10/11 18:11, John W. Eaton wrote:
> Earlier, we discussed using a singleton object that follows the 
> pattern of other singleton objects in Octave to implement the 
> profiler.  Looking at the current code, it doesn't seem to use that 
> style, but is just using a single global instance of the 
> profile_data_accumulator object.  Why?

IIRC, your argument for the Singleton pattern was order of
initialization -- but since my class doesn't depend on any particularly
complex initialization (and in particular not on any order relative to
other things in Octave), I think a plain global instance is clearer and
cleaner.  Besides, as you noted below, that part of the code could in
principle handle multiple accumulators in parallel (without any "cost"
to the implementation complexity here) -- which is IMHO a good thing,
and adding some code to get a "Singleton pattern" would make things more
complicated for no gain.

But please note that this is of course just my opinion, and also that
I've never been in favor of the Singleton pattern myself (well, I never
really felt the need for it nor thought about using it).

> The current implementation of the profile_data_accumulator::enter 
> object appears to allow data to be collected in multiple accumulator 
> objects, but then the code that uses this class, like
> 
> { profile_data_accumulator::enter pe (profiler, profiler_name ()); 
> cmd_list->accept (*current_evaluator); }
> 
> only uses the global profiler object.  It seems to me that this code 
> would have to change if you wanted to collect data in a different 
> global accumulator object.
> 
> If you just want a single accumulator object, then I don't see the
> point of passing it as an argument to the 
> profile_data_accumulator::enter object.  It seems it could just be 
> contained inside the profile_data_accumulator object.

My intention behind this is similar to mine above -- the code in
profiler.cc (which I think of as "profiler implementation") is basically
not restricted to a single one (because it needs not be) -- and that
also means that profile_data_accumulator::enter is not, ergo we have to
tell it which profiler to use.

But since we in fact only have one profiler at the moment, the "user
code" has this single profiler instance hard-coded.  I don't think the
additional "profiler" argument hurts or makes things much harder to
understand (but of course others may disagree, I don't know).

Does this make things clearer?  If not, what has not been covered by my
attempt to explain?

Yours,
Daniel


- -- 
OpenPGP: 3BA2 3DDB 7758 F010 BDAB 0DCF 527E 79BA A3B5 3998
or use https://safesend.domob.eu/
- --
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOQrfAAAoJEFJ+ebqjtTmYBA0QAIB5jMlbkMUE7lqFjE/P6xaz
tDrWMHkmUxLzVFL9031T4cf+CH0qmfNN8o9yPiOa1qBz3zoPUUNn6u74NRewSsiw
OuZwfMvPUWWzD7q0ueNka3PQpNZx0QTJUtBRgbanXKnGrCGVyxsYmD1j5d0GR6+v
g3TcVAzD2B9jcvaMR47N0gZy0M0GwBhobAJpIYNHRVpjfag93YpWdWyLrESoqscB
VCgSaRAGg87n99NYtkDv/SSUhs/bqO/FlZtRUsQKayaSlsGOp4bd0ajqAPxn4qBe
2nObaZn+SF88jQE99OGigAZ3FM17RlclfR1AYOkROv1Jg9jOztqCg0JjdhBow9yX
IWxFBTHY+/pIP4BQj0N9atdp377byB433veg7tVVYjS01OkpqxSFEhu+oJkGyipk
VUlAKH2oSnztlZKI8GlK50dusydya3R58LbZfxxHIp2FONRKyakJ9duEhiHRBzGE
5H185zKOnfFjpBQ1fGR3JhwEBlvkvCU0IE/XNctvUNeKnJq3j1zzGTIiD9xsMkiW
e06pE885w/tYPZP7e0HiWwkaui8oEG7rGCe3BtcqbbIVeCCO1YxXHr33jCK7rGNK
K6fL8gbAA1/epeR3Cz5ewtmJeQKkodMK4WBR6fGIbXyOe7vK+HX8x/B8Z9vHT3OW
BeTk8TuBUSXsYgMg55AA
=ngMn
-----END PGP SIGNATURE-----

smime.p7s
Description: S/MIME Cryptographic Signature