Re: Re: Profiling forking code?

$ENV{PERL_DPROF_OUT_FILE_NAME} = "foo${$}.out"; is how to change that. I've never tried profiling over a fork, though.

It looks as if the child will have to be started with that environment variable localized.

Update: I have tried it now, couldn't work it without going through the shell,
file prof.pl:

#!/usr/bin/perl  -d:DProf

{
    local $ENV{PERL_DPROF_OUT_FILE_NAME} = "foo.out";
    my $cpid = open my $foo, '|-', '/usr/bin/perl -d:DProf profc.pl' o
+r die $!;
}

print 'In Parent', $/ or die $!;
sleep 10;
[download]

file profc.pl:

#!/usr/bin/perl

print 'In Child',$/ or die $!;
sleep 10;
[download]

$ ./prof.pl In Child In Parent $ ls *.out foo.out tmon.out After Compline, Zaxo Comment on Re: Re: Profiling forking code? Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Profiling forking code? by BrowserUk (Patriarch) on Jan 13, 2003 at 19:22 UTC
Yes, I discovered that to, but couldn't work out how you might cause fork to start a new copy of the debugger with that variable changed. I did think that as AS forks are implemented as threads of the same process, by modifying module so that it incorporated the threadID in the name of the output file at runtime, it might be possible to get a new output file for each process (thread), but as I said, when I loked at the C-source for the .DLL, I found myself going in circles trying to unwind the macros involved and gave up. Even ignoring the macros problem, it was not at all obvious to me whether the debugger could be coerced into using a different handle within each thread, nor whether it would be threadsafe. I was looking at the source for AS 5.6.1 at the time. In the end, I started playing with the idea of using Benchmark::Timer dynamically required by each child process after it was forked and outputting the results to files opened by the child processes after forking incorporating the psuedo-process ID, but I found my problem before persuing that idea any further. The biggest problem with that idea is that you end up having to modify the program under test in order to profile, which is less than desirable. Examine what is said, not who speaks. The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Profiling forking code?
by BrowserUk (Patriarch) on Jan 13, 2003 at 19:22 UTC

Yes, I discovered that to, but couldn't work out how you might cause fork to start a new copy of the debugger with that variable changed.

I did think that as AS forks are implemented as threads of the same process, by modifying module so that it incorporated the threadID in the name of the output file at runtime, it might be possible to get a new output file for each process (thread), but as I said, when I loked at the C-source for the .DLL, I found myself going in circles trying to unwind the macros involved and gave up. Even ignoring the macros problem, it was not at all obvious to me whether the debugger could be coerced into using a different handle within each thread, nor whether it would be threadsafe. I was looking at the source for AS 5.6.1 at the time.

In the end, I started playing with the idea of using Benchmark::Timer dynamically required by each child process after it was forked and outputting the results to files opened by the child processes after forking incorporating the psuedo-process ID, but I found my problem before persuing that idea any further. The biggest problem with that idea is that you end up having to modify the program under test in order to profile, which is less than desirable.

Examine what is said, not who speaks.

The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.

[reply]