Re: [Patch, Profiler] Profiling of operators

[Daniel Kraft]

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

On 08/05/11 06:43, Jordi Gutiérrez Hermoso wrote:
> Hi, Daniel. I've pushed your changes, with a slight change in the 
> comments, to slightly redundantly include what you said about the 
> entanglement of the boolean operators.
> 
> http://hg.savannah.gnu.org/hgweb/octave/graph

Thanks!

> On 29 July 2011 11:23, Daniel Kraft <address@hidden> wrote:
> 
>> this patch implements profiling of operators. It was not that
>> hard, after all ... only now the profile_data_accumulator *only*
>> works on the strings identifying functions and never
>> octave_function references. This is necessary because (AFAIK)
>> operators don't have any octave_function corresponding to them. But
>> it seems to work the way it is now.
> 
> This worries me a little. Is this no significant speed penalty on
> the profiler? Quis profiliet ipsos profiles? Who profiles the
> profilers? ;-)

We already decided to use the profiler name (as std::string) as index
into a std::map to store the data at the very beginning (jwe suggested
that instead of the pointers to the function objects).  I don't know
whether that is "slow" or not, but so far it seems not to make any problems.

> I couldn't notice a speed difference, but perhaps you could explain
> to me in general. Will the profiling code affect execution speed
> while the profiler is not active?

What is "new" with the current patch is that now we always call
octave_function::profiler_name() in addition; that is also done when
profiling is disabled.  If we find out that it hurts performance, I
could rewrite the code so that profiler_name() is only called when
actually profiling -- but the current code is probably a little nicer
and clearer.

Apart from that, we basically check whether profiling is enabled (in the
profile_data_accumulator::enter constructor) and that's it, if we're
disabled.

But if you are unsure, I could try to run octave through gprof to
extract the time that is spent inside the profiling system; do you think
that would be worthwhile?  Maybe when the basic implementation is finished.

> Also, how are you coming along with anonymous functions? Is there 
> something you need help with?

Honestly, I had little time the last few days (because I have two exams
early next week) -- but it should get better today and starting next week.

In principle, anonymous functions "should" already work since the very
first patch -- I had code in there to collect the row/column of their
definition, but it seemingly does not work.  So I'm trying to figure out
what goes wrong and where to get those values correctly.  Again, this
will (probably) just be a small patch -- if I can find out the correct
place to get the info from. ;)

At the moment, there are no concrete questions -- but if I fail to get
the data, I'll ask. :)

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/

iQIcBAEBAgAGBQJOO7vpAAoJEFJ+ebqjtTmY0JkP/1CIhlHxtn/cNN5BHmxwOEZa
tp47kYoNBMXZODvuksOdTIcQmUXgi6ASwmcl4kw4QTLiU7CSEivvT68p0NJ9ukXq
8GTcxgEpX6RGtUuHh71/swaLPNL1dsrKKf4Rum4ypJ2tiKDTfNRxD8e5/xHkDNKv
dRod0MAg9JlqwDEo8eGVTQ/QhgN0C7YsgypG4t6/uCxE6PGFyQ5hDX0pl9w1OePG
dy/56tXGUzM1MNUIsHB/hW8s8DCgnaIfkYflJccT7IFKvZsUUpEDKsJXxPILbzaH
T7pfmnDZ2ppHxG4yBRqp5CWv+G04UZeFfJdZmQvkxHL2Kq05f4Kyr0GQMBt/yYDr
zAnNpQyfK3dClKJXU8HqpD4eRbrcuOw7etvTHi0Q1xUIe29qAMgwvdK+hawDpZ5o
k0vEemJYJHjKtiaEiK2E80Jb1J5OGJ2cDQZlmMI9WkOo4Uf8l6ow0b50Ye66c/6g
KCVbNoSs0eUUCMMD8zimoHhDwgTlBBqzs45XYZptK7vBx32QXh7toIYh0fzd4wJO
tMzf0+ei9hqEk72nByf3qDYGjWz2iX9lXD3ZxCzwRj2sESC4exnqeTZk8IlgwSh+
z6/xbwdm4gKXjVqD/L+Yju7EsEUudEDEKfSIjojmisqwMQQBureuqUeeCUMry6VP
dXwJAr/BR75DCLE0C/6P
=+XTs
-----END PGP SIGNATURE-----

smime.p7s
Description: S/MIME Cryptographic Signature