document how to profile - gprof

[jelte]

For now, a wiki page is with the needed steps is enough I think; so it would at the very least need to contain:

• how to set up system and/or environment
• how to compile for it
• how to run it
• how to check results

[jelte]

When you have created a wiki page for this, please add or update the link on http://bind10.isc.org/wiki/ProfilingHowto

[haikuo]

when we use "pg" option to build bind10 software, all the ELF executable files(eg. b10-auth and b10-resolver in PATH/libexec/bind10-devel/) would produce the same default profiling file which named "gmon.out" at the same working directory.
If want to produce different files, we should assign different values to the "GMON_OUT_PREFIX" environmental variable when spawn different sub-processes. Take from example, b10-auth ELF executable file will produce b10-auth.PID file if we assign "b10-auth" to "GMON_OUT_PREFIX",and b10-resolver ELF executable file will produce b10-resolver.PID file when we assign "b10-resolver" to "GMON_OUT_PREFIX".

I have a suggestion to handle the name conflict. we could modify the bind10 scripts in PATH/sbin, add "spawn_envGMON_OUT_PREFIX? = self.args[0]" to _spawn function, like that:

[zhanghk@iscloud01 tmp]$ diff bind10 bind10-new
144a145

spawn_envGMON_OUT_PREFIX? = self.args[0]

then bind10 will produce different profiling files, and we can use gprof to collect data for the differenct ELF executable files .

[jinmei]

Replying to haikuo:

I have a suggestion to handle the name conflict. we could modify the bind10 scripts in PATH/sbin, add "spawn_env[ 'GMON_OUT_PREFIX' ] = self.args[0]" to _spawn function, like that:

[zhanghk@iscloud01 tmp]$ diff bind10 bind10-new
144a145

spawn_env[ 'GMON_OUT_PREFIX' ] = self.args[0]

then bind10 will produce different profiling files, and we can use gprof to collect data for the differenct ELF executable files .

I personally would like to avoid hardcoding profiling specific
environment variable name to the script source. IMO any hardcode is
generally evil and make the implementation less maintainable, and
especially in this case this information is unnecessary in the vast
majority of actual usage (running it in a production environment or in
tests).

I'd suggest considering a different approach, such as tweaking
run_bind10.sh script where the additional env variable is defined.

[haikuo]

Definitely jinmei is right,hardcoding only for profiling feature would cause difficulty to maintenance. But from my point of view, tweaking run_bind10.sh script is not a perfect approach, because it is hard for our bind10 user to modify bind10 code. If we are the only users for profiling feature, Jinmei's approach is OK.
If we launch the "run_bind10.sh" scripts, we have to maintain one more file, it may be hard for us.

Could we add an option for bind10 script(PREFIX/sbin/bind10)? like "--profiling" or something. then bind10 could open the switch to assign the environment variable.

[haikuo]

the initial version of documentation for this ticket is done,please review it.
http://bind10.isc.org/wiki/ProfilingGprof

[haikuo]

the initial version of documentation for this ticket is done, but the discussion about this profiling approach should go on

[vorner]

Hello

I'd have few minor details:

By „Assign “pg” to CXXFLAGS“ you mean CXXFLAGS='-pg'? Did the dash get eaten by wiki formatting?

The diff output would be better as unified diff, to see the context around it. This way, if we change the source file of boss, the line numbers might get wrong.

Does your system really have a capital 'G' in 'Gprof'? Mine is with lowercase, so I believe this could be a result of some editor automatic correction, or something like that.

With regard to the profiling variables being in boss, I don't really like that. And I don't think an ordinary user ever wants to do profiling, if someone wanted to do that, he would be a developer already and editing a little bit of code shouldn't be a big problem.

I thought of a different way to handle this. The file is saved to the current directory where the program exits. Maybe having a different directory to run in for each of the processes would be helpful. But changing the directories has the same problem as changing the environment, we are adding support for profiling when most users don't want it.

Thank you

[haikuo]

Form my side, vorner's suggestion is reasonable, I have updated the wiki. please review it again.

for the suggestion about different directory to run different sub-processes, I think it could be more difficult than my approach. but this suggestion could be considered as candidate solution for user.I agree that the user of profiling tools must be a developer, so they have the ability to modify codes for the profiling feature.

thanks for vorner's suggestion.

[jreed]

I made some very minor edits to the wiki page.

[vorner]

Hello

Replying to haikuo:

Form my side, vorner's suggestion is reasonable, I have updated the wiki. please review it again.

Thanks. I did one very minor change there (replaced long dashes with the correct short ones in the examples).

for the suggestion about different directory to run different sub-processes, I think it could be more difficult than my approach. but this suggestion could be considered as candidate solution for user.I agree that the user of profiling tools must be a developer, so they have the ability to modify codes for the profiling feature.

Right, that one with directories might have been a stupid idea. But I just wrote it if it turned out to be of any use.

Anyway, I think it looks OK, I think this can be called „done“.

Thank you

[haikuo]

thanks for the reviewing,and this ticket is done