Sponsored Content
Top Forums Programming function profiler for HPUX...? Post 58251 by clockworks on Tuesday 16th of November 2004 04:07:58 PM
Old 11-16-2004
function profiler for HPUX...?

I need some kind of profiler that will tell me how much time is spent in each function. I'm running HPUX. Thanks for the suggestions.
 

4 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Need Script to Use CPUs on a HPUX server to simulate Workload Manager on HPUX.

I am running HPUX and using WLM (workload manager). I want to write a script to fork CPUs to basically take CPUs from other servers to show that the communication is working and CPU licensing is working. Basically, I want to build a script that will use up CPU on a server. Any ideas? (2 Replies)
Discussion started by: cpolikowsky
2 Replies

2. Programming

C/C++ Appliaction Profiler

Dear All, I have my C/C++ appliaction running on Sun Solaris 5.9. Can any of you please suggest a profiler which i can use for improving the code performance. Please reply as i am stuck with the performance of the code. (1 Reply)
Discussion started by: ashisharora
1 Replies

3. Shell Programming and Scripting

profiler

What is a hard and soft match in unix profiler ??? (1 Reply)
Discussion started by: ekharvi
1 Replies

4. HP-UX

pwage-hpux-T for Trusted HPUX servers

I'm sharing this in case anybody needs it. Modified from the original solaris pwage script. This modified hpux script will check /etc/password file on hpux trusted systems search /tcb and grep the required u_succhg field. Calculate days to expiry and notify users via email. original solaris... (2 Replies)
Discussion started by: sparcguy
2 Replies
Devel::NYTProf::Core(3pm)				User Contributed Perl Documentation				 Devel::NYTProf::Core(3pm)

NAME
Devel::NYTProf::Core - load internals of Devel::NYTProf DESCRIPTION
This module is not meant to be used directly. See Devel::NYTProf, Devel::NYTProf::Data, and Devel::NYTProf::Reader. While it's not meant to be used directly, it is a handy place to document some internals. SUBROUTINE PROFILER
The subroutine profiler intercepts the "entersub" opcode which perl uses to invoke a subroutine, both XS subs (henceforth xsubs) and pure perl subs. The following sections outline the way the subroutine profiler works: Before the subroutine call The profiler records the current time, the current value of cumulative_subr_secs (as initial_subr_secs), and the current cumulative_overhead_ticks (as initial_overhead_ticks). The statement profiler measures time at the start and end of processing for each statement (so time spent in the profiler, writing to the file for example, is excluded.) It accumulates the measured overhead into the cumulative_overhead_ticks variable. In a similar way, the subroutine profiler measures the exclusive time spent in subroutines and accumulates it into the cumulative_subr_secs global. Make the subroutine call The call is made by executing the original perl internal code for the "entersub" opcode. Calling a perl subroutine If the sub being called is a perl sub then when the entersub opcode returns, back into the subroutine profiler, the subroutine has been 'entered' but the first opcode of the subroutine hasn't been executed yet. Crucially though, a new scope has been entered by the entersub opcode. The subroutine profiler then pushes a destructor onto the context stack. The destructor is effectively just inside the sub, like a "local", and so will be triggered when the subroutine exits by any means. Also, because it was the first thing push onto the context stack, it will be triggered after any activity caused by the subroutines scope exiting. When the destructor is invoked it calls a function which completes the measurement of the time spent in the sub (see below). In this way the profiling of perl subroutines is very accurate and robust. Calling an xsub If the sub being called is an xsub, then control doesn't return from the entersub opcode until the xsub has returned. The profiler detects this and calls the function which completes the measurement of the time spent in the xsub. So far so good, but there's a problem. What if the xsub doesn't return normally but throws an exception instead? In that case (currently) the profiler acts as if the xsub was never called. Time spent inside the xsub will be allocated to the calling sub. Completing the measurement The function which completes the timing of a subroutine call does the following: It calculates the time spent in the statement profiler: overhead_ticks = cumulative_overhead_ticks - initial_overhead_ticks and subtracts that from the total time spent 'inside' the subroutine: incl_subr_sec = (time now - time call was made) - overhead_ticks That gives us an accurate inclusive time. To get the exclusive time it calculates the time spent in subroutines called from the subroutine call we're measuring: called_sub_secs = cumulative_subr_secs - initial_subr_secs and subtracts that from the incl_subr_sec: excl_subr_sec = incl_subr_sec - called_sub_secs To make that easier to follow, consider a call to a sub that calls no others. In that case cumulative_subr_secs remains unchanged during the call, so called_sub_secs is zero, and excl_subr_sec is the same as incl_subr_sec. Finally, it adds the exclusive time to the cumulative exclusive time: cumulative_subr_secs += excl_subr_sec AUTHOR
Tim Bunce, <http://www.tim.bunce.name> and <http://blog.timbunce.org> COPYRIGHT AND LICENSE
Copyright (C) 2008, 2009 by Tim Bunce. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.8 or, at your option, any later version of Perl 5 you may have available. perl v5.14.2 2010-11-19 Devel::NYTProf::Core(3pm)
All times are GMT -4. The time now is 06:49 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy