I don't know why you're getting this exact behavior, but given that the debugger does affect the way perl runs (inserting breakpoints and what not into the normal op tree flow) it's not inconceivable that it would throw timing sensitive code off at least a bit.

I agree the debugger will likely run the code more slowly, but that means that the values from gettimeofday() should be more widely spaced, not grouped together the way they are.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

My guess is that print $INC{'Time/HiRes.pm'} will show differently (not sure why, though).

Good thought, but no.

P:\test>perl -MTime::HiRes=gettimeofday -le"print $INC{'Time/HiRes.pm'
+}"
c:/Perl/lib/Time/HiRes.pm

P:\test>perl -de1
perldb: Must not source insecure rcfile ./perldb.ini.
        You or the superuser must be the owner, and it must not
        be writable by anyone but its owner.

Loading DB routines from perl5db.pl version 1.25
Editor support available.

Enter h or `h h' for help, or `perldoc perldebug' for more help.

main::(-e:1):   1
  DB<1> use Time::HiRes qw[gettimeofday];

  DB<2> print $INC{'Time/HiRes.pm'}
c:/Perl/lib/Time/HiRes.pm
  DB<3>
[download]

I also tried to verify that the import was working properly, and it seems to be:

  DB<4> print \&GLOBAL::CORE::gettimeofday, $/, \&main::gettimeofday, 
+$/, \&Time::HiRes::gettimeofday
CODE(0x1b28118)
CODE(0x1a7e034)
CODE(0x1a7e034)
  DB<5> print __PACKAGE__
main
[download]

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

1002% perl -MTime::HiRes=gettimeofday -le"print scalar gettimeofday() 
+for 1..10;"
1090268974.51822
1090268974.5186
1090268974.51873
1090268974.51886
1090268974.51899
1090268974.51911
1090268974.51924
1090268974.51936
1090268974.51949
1090268974.51961
1003% perl -de1

Loading DB routines from perl5db.pl version 1.19
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1):   1
  DB<1>  use Time::HiRes qw[gettimeofday];

  DB<2> print scalar gettimeofday(), $/ for 1 .. 10;
1090269029.69885
1090269029.69905
1090269029.69912
1090269029.6992
1090269029.6993
1090269029.69937
1090269029.69944
1090269029.69951
1090269029.69959
1090269029.69966
[download]

Indeed.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

BTW, I get the lower-resolution results even w/o the debugger (but I've got 5.6.0 here).

- tye        

Dave.

It might be interesting to run under the debugger in several DOS windows: set each to loop long enough that you can switch windows and start the others.

Send the output to file, process with "uniq".

Append a tag (a, b, c...) to each line, merge and sort the files. I'd guess the uniq'd, merged, sorted file would be similarly blocky, but that the lines would be close to a, b, c order.

Please note that both tests are running on the same system, using the same version of perl. The *only* difference is the use of the perl debugger.

Besides which, if it were "windows making perl wait", the times would get spread wider apart, not grouped together in bunches. The latter effect suggests that perl is calling gettimeofday() more frequently that the timer is running.

Given the timer is running 3,579,545 times a second, to produce the list of 30 consequetively identical times, The debugger would have to be running the loop 90 million times a second. Which would be nice, but I think we may have to wait for P7 to achieve that kind of performance :)

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon