CPU usage of GetTickCount

[typo]

I have a function like this:

Code: [Select]

procedure Delay(MiliSeconds :integer);
var
  tc :integer;
begin
  tc := GetTickCount;
  while GetTickCount < tc + MiliSeconds do
    Application.ProcessMessages;
end;

Is there any advantage on changing it by:

Code: [Select]

procedure Delay(MiliSeconds :integer);
var
  tc :integer;
begin
  tc := GetTickCount;
  while GetTickCount < tc + MiliSeconds do
  begin
    Sleep(MiliSeconds div 10);
    Application.ProcessMessages;
  end;
end;

in terms of CPU usage?

Thanks.

[marcov]

Yes, that is better. Keep in mind that processmessages drains the queue with messages empty anyway. So each iteration processes new messages.

Of course it is wise to avoids these kinds of constructs as much as possible, since they are essentially a band-aid for flaws else where. I had to rip something similar completely from the active parts of my apps since when the application was busy, the codepaths became totally unpredictable. I now only use it during startup and shutdown. (when the main event sources that make the application busy either haven't started yet, or have been signaled to terminate)

[User137]

If you want to always run sleep at least once, you can change it to

Code: [Select]

Sleep(1+MiliSeconds div 10);This is much lighter on the CPU.

Or simply this would save propably same amount of CPU:

Code: [Select]

Sleep(1);

[typo]

Of course it is wise to avoids these kinds of constructs as much as possible, since they are essentially a band-aid for flaws else where.

Maybe LazUtils could provide these good-practice ready-to-use routines. People don't like that their user lose the control of the program while sleep-ing, so they often use constructs like that.

[marcov]

Maybe LazUtils could provide these good-practice ready-to-use routines.

That's the problem, and why I would hesitate to make them public. They are not good practice, but occasionally allow you to "get by", and not move
something to a different thread, or work around bugs in external code.

People don't like that their user lose the control of the prgram while sleep-ing, so they often use constructs like that.

Most programmers are afraid of threads, and will go to great lengths to avoid them (and the GUI-code separation that comes with them). That doesn't make it right though.

[User137]

TTimer is designed for sole purpose of giving near exact delay between executions, while saving CPU at the same time. Simpler to implement than threads too.

[typo]

TTimer is an over-solution for a single call of a delay.