in reply to Re: Timer implementation
in thread Timer implementation

My application is cgi script. I need at least milli-second. My code is very simple. At case of times(). I use: 

$start = [times()];
...somecode...
$end = [times()];


$time_diff =($start->[0] + $start->[1]) - ($end->[0] + $end->[1]);

[download]
at case of Time::HiRes 
$start=[gettimeofday];
...somecode...
$end = [gettimeofday];

$time_diff = tv_interval($start, $end);

[download]
But if real <=> sys+user, my first case will be always lower that at case 2

Replies are listed 'Best First'.
Re^3: Timer implementation
by GrandFather (Saint) on Sep 16, 2008 at 02:29 UTC

    Your implementation context is CGI script, but that is not your application. Your application may be timing a database query or some such. So, what is the application?

    You need to decide what it is that you want to report - wall clock time or process time.

    With most operating systems that are not designed for real time environments reporting wall clock times of less than a few milliseconds is fairly meaningless because time slices for tasks are of that order and will render any real time reporting at that level meaningless.

    Perl reduces RSI - it saves typing
[reply]
      My application is CGI script that works with SQLite and does a lot of text manipulation works.
      Of course i need wall clock to know is it my script works so slowly or it is slow network throughput.
      If script works slowly, then i will know that i need to do some code optimization.
      But if i got situation where real time is much more bigger than sys+real time. What to do in this case? And is it possible case? If I understand correctly it's possible at case where CPU is busy by other process or my process is sleeping on I/O system calls. If it's true - robust timer should include all three number - real, system and user times. Am i right?
[reply]

        So your "application" is "timing server side performance for a CGI script". If you are interested in perceived slowness by a real user then any time period less than 1/2 a second is uninteresting. Trying to measure times with 1 ms resolution in that context is neither meaningful nor useful.

        Wall clock time for the server process is the only thing of interest to a "someone" at the far end of the pipe and that can be obtained using Time::HiRes::gettimeofday. If you determine that there is a performance issue on the server then you have the harder task of determining where the bottle neck is.

        Perl reduces RSI - it saves typing
[reply]
        Er... wasn't it so that the user and system times only concern the current process, not its possible children? That's my reading of the man page, and has been my belief so far.
        The real time of course does take the children into account...
[reply]

        Real time is the real time elapsed. System time is the time the kernel has been busy with your system calls. User time is the time spent in user space.

        systime + usertime = realtime is true only if your process is the only process on the box, and if the kernel does all its fiddlings in no time. But you aren't interested in absolute times, but in relative - to identify bottlenecks.

        To do so, time chunks of your application using Time::HiRes. Separate CPU intensive tasks from disk (also database) I/O and network I/O. You might want to run certain tasks in "dry run mode", eliminating I/O as much as possible. The sums of elapsed times will give you hints, but of course, those can be grossly distorted by other tasks running with higher priority than the ones you are observing.

[reply]
[d/l]

In Section Seekers of Perl Wisdom