Why a Delphi progressbar increases the execution time of a iteration procedure? - delphi

Question

Why the use of a progress bar to show the progress of an iteration considerably increases the execution time of the process in question?
Considering the following example:
procedure FileToStringList(FileName: String);
var
fileSource: TStringList;
I: Integer;
begin
fileSource:= TStringList.Create;
try
fileSource.LoadFromFile(FileName);
for I := 0 to fileSource.Count - 1 do
begin
//Code....
end;
finally
fileSource.Free;
end;
end;
If you add the update of a progress bar:
procedure FileToStringList(FileName: String);
var
fileSource: TStringList;
I: Integer;
begin
fileSource:= TStringList.Create;
try
fileSource.LoadFromFile(FileName);
ProgressBar.Properties.Max:= fileSource.Count;
for I := 0 to fileSource.Count - 1 do
begin
Application.ProcessMessages;
ProgressBar.Position:= I;
end;
finally
fileSource.Free;
end;
end;
The time required for the iteration process to be performed is multiplied enormously.
Performing a reading test of a file of 200,000 lines, without the update of the progress bar, the time of the iteration is approximately 8 seconds but, if the update of the progress bar is activated to show the progress of the iteration, this process takes several minutes.
A test with a file of 2,700 lines, the normal time is 2-4 seconds but with the use of a progress bar, the execution time is more than 1 minute.
Can someone indicate if the use of the Application ProcessMessages is incorrect?. The result does not change if the routine is in a unit or on the same form like the progress bar.
Okay I can see the comments but, can someone indicate with an example or link which should be the correct way to update the progress bar in these conditions?

Answer 1

You're not really "just adding a progress bar". Your use of Application.ProcessMessages; messages means that you're also pumping all manner of additional messages doing other work. So now your "busy/main work" is competing for CPU time on the same thread (and CPU) as all the other messages going through your application. We're certainly in no position to comment on what other messages might be flowing though your application.
Busy work should not be done in the main thread. And it's generally fairly easy to wrap a method into a thread provided it isn't already too tightly coupled to your GUI.
No doubt you've been told all this in comments already.
First take note of a few important rules:
don't interact with your GUI from your child threads (Synchronise or Queue calls to code that updates GUI);
avoid sharing data1 between threads (including main thread);
if you must share data ensure your threads co-ordinate1 their access to avoid race conditions (too big a topic to go into detail).
Then the following is the minimum needed:
Define your thread.
Implement your main processing in the Execute() method.
Create and start your thread.
Since you want to update a progress bar, and remembering "Rules to note": make sure you Queue those updates.
But there are a number of more advanced considerations you can apply to improving your thread. (Those will be left to you for further research.)
You would also be well advised to also take advice Ive and others have already given and reduce the number of times you update your progress. Excessive updates just wastes time; especially with cross-thread operations (see last section).
How do you interrupt your thread if your user wants to cancel the job or close the app?
How do you manage the possibility of your user starting too many jobs?
How do you deal with errors in your threads?
How do you want to manage what happens when your thread terminates.
The following sample code is a trimmed down version of what you need in 1-4. You can fill in the trivial bits I left out.
1)
type
TFileProcessor = class(TThread)
public
constructor Create(const AFileName: string);
procedure Execute; override;
end;
2 & 4)
Note that you could pass the progress bar instance in your constructor and update it from your thread. But even though it's a little more work, it's much cleaner to define a callback event on your thread, and allow your GUI to handle the event in order to choose exactly what it wishes to do.
procedure TFileProcessor.Execute;
var
fileSource: TStringList;
I: Integer;
begin
fileSource:= TStringList.Create;
try
fileSource.LoadFromFile(FileName);
{ GUI interaction must be queued.
ProgressBar.Properties.Max:= fileSource.Count;}
FPosition := 0;
FCount := fileSource.Count;
Queue(DoUpdateProgress);
for I := 0 to fileSource.Count - 1 do
begin
{ Obviously this must go!
Application.ProcessMessages;}
{ Again GUI interaction must be Queued
ProgressBar.Position:= I;}
FPosition := I;
Queue(DoUpdateProgress); {TIP: Reduce your progress updates for
more performance improvement; updating
on every single line is overkill.}
end;
finally
fileSource.Free;
end;
end;
procedure TFileProcessor.DoUpdateProgress();
begin
if Assigned(FOnUpdateProgress) then
FOnUpdateProgress(FPosition, FCount);
end;
3)
procedure TForm1.Button1Click(...);
var
LThread: TFileProcessor;
begin
LThread := TFileProcessor.Create(FFileName);
LThread.OnUpdateProgress := HandleUpdateProgress;
LThread.FreeOnTerminate := True;
LThread.Start;
end;
4)
As mentioned earlier it's cleaner if your form controls what GUI controls it wants to update and how in response to progress updates. E.g. You could update a label at the same same time if desired without any change to the thread and job code.
procedure TForm1.HandleUpdateProgress(APosition, ACount: Integer);
begin
ProgressBar.Position := APosition;
ProgressBar.Properties.Max := ACount;
Label1.Caption := Format('Line %d of %d', [APosition, ACount]);
end;
1 I'd like to emphasise the point that you should avoid sharing data with multi-threaded code. Cross-thread operations are much more expensive than same-thread operations. (This includes notifications to the main thread.)
For example, on my system, the thread code above has the following overheads.
200,000 Queued events to the main thread has an overhead of almost 1 second.
Depending on what you do inside HandleUpdateProgress you might find it takes some time processing all the queued messages for a while after your file has actually finished processing. (On my system updating a standard label and progress bar, this takes 5 seconds.)

Answer 2

If your application only transforms the input file, then there is no need for a special thread and you can use following code.
In the case that an application allows the user to perform another operations while processing the file, then a background thread should be used.
procedure FileToStringList(FileName: String);
var
fileSource: TStringList;
I,J: Integer;
begin
fileSource:= TStringList.Create;
try
fileSource.LoadFromFile(FileName);
ProgressBar.Properties.Max:= fileSource.Count;
J:=10;//TODO make it better
for I := 0 to fileSource.Count - 1 do
begin
if (I mod J = 0) then
begin
Application.ProcessMessages;
ProgressBar.Position:= I;
end;
end;
ProgressBar.Position:= fileSource.Count;
finally
fileSource.Free;
end;
end;
Or you can call your processMessages on time:
procedure FileToStringList(FileName: String);
var
fileSource: TStringList;
I,J: Integer;
lastCheck: TDateTime;
begin
fileSource:= TStringList.Create;
try
fileSource.LoadFromFile(FileName);
ProgressBar.Properties.Max:= fileSource.Count;
J:=1000;//refresh in ms
lastCheck:=now;
for I := 0 to fileSource.Count - 1 do
begin
if (lastCheck+j)<now then
begin
lastCheck:=now;
Application.ProcessMessages;
ProgressBar.Position:= I;
end;
end;
ProgressBar.Position:= fileSource.Count;
finally
fileSource.Free;
end;
end;