Ada.Real_Time behavior with GNAT

[kongra <kongra@gmail.com>]

Hi everybody.

I have a question related to the Ada.Real_Time package. When I compile
the following code using GNAT GPL 2007 on Windows XP SP2 I observe
some strange looking behavior.

with Ada.Real_Time;
with Ada.Text_IO;

procedure Timing is
   Start_T : Ada.Real_Time.Time;
   End_T   : Ada.Real_Time.Time;
   Total_T : Duration;
   Sleep_T : constant Duration := Duration (0.0001);

   use Ada.Real_Time;

   Val : Integer := 0;
begin
   -- delay Sleep_T;
   Start_T := Ada.Real_Time.Clock;
   for K in 1 .. 10 loop
      for I in 1 .. 10_000_000 loop
         Val := Val + I;
      end loop;
   end loop;
   End_T   := Ada.Real_Time.Clock;
   Total_T := Ada.Real_Time.To_Duration (End_T - Start_T);
   Ada.Text_IO.Put_Line (Integer'Image (Val));
   Ada.Text_IO.Put_Line (Duration'Image (Total_T));
end Timing;

The compilation command is pretty straightforward: gnatmake Timing.adb
-o timing.exe. Running timing.exe I get

1432236160
0.000000000

To my surprise the total time is 0 here, though performing all the
computations takes some observable time. However removing comment in
the line containing statement delay Sleep_T; causes

1432236160
0.431441426

Apparently the total duration seems correct now. I get a similar
change by putting

with Ada.Calendar;

to the compilation unit (without completely using it). Moreover the
delay statement has got the same impact on the program execution even
when it's placed in some procedure other than Timing and the procedure
is not used at all.

I tried the same code in a bigger project using switches like those in
the Ada Wikibooks examples, getting the same.

Can it be explained or is there something I don't know about timing in
Ada ? I'm a beginner in Ada (after 7+ years Java coding) and I think
it's a great programming language, worth to be promoted among
students. But this one really surprised me even if I was able to avoid
using Ada.Calendar (for example prohibited by Ravenscar profile) using
a hack with delay.

Best regards,

Konrad Grzanek.