It’s good practice to program dialogs to inform users on the state or progress of a process.
Like in standard NAV when posting a sales invoice:
or a journal:
But did you ever had to post dozens (or even hundreds or thousands) of sales invoices or journal lines? Or had programmed a batch job for you customer with a nice progress dialog and when executed seemed to last for ages?
Please, if you never have known this before, store this in some drawer of your mind at hand to your daily conscious:
Every update of a progress dialog degrades the performance of NAV
Dialog Performance Test
With the attached this .fob file we have a simple example to illustrate this performance degradation.
The .fob contains the following form (Test Dialog Performance – 88888):
Pushing the Run Dialog button will execute the following code:
Count := 0;
StartTime := TIME;
FOR Count := 1 TO TotalIterations DO
IF Count MOD UpdateDialogAfter = 0 THEN
EndTime := TIME;
TimeElapsed := EndTime – StartTime;
Showing this progress dialog:
If we run the dialog, using the default values, one hundred thousand iterations (i.e. Total Iterations = 100,000) will be performed and with every iteration (i.e. Update Dialog After = 1) the progress dialog will be updated.
On the old machine I ran this test on it took approximately 60,000 ms.
However, if we diminish the number of updates to the progress dialog from every iteration to every hundredths iteration (i.e. Update Dialog After = 1), the total of 100,000 iterations will be completed in approximately 650 ms. So now my process runs almost 100 times faster! [:^)]
In case your batch job took one night to run – let’s say 10 hours – it would be possible to speed it up so it would run in less than … 10 minutes! Well, maybe not that fast as your batch job will have a lot of lines of codes extra for processing data. Speeding up by a factor 10 is not unrealistic.
- You might wonder why standard NAV updates the progress dialog with every line when posting a journal … [:S]
- A side effect of using a progress dialog is that a Cancel button is provided to the user so she has to possibility of canceling the process running.
BTW: Did some test today on RTC (after transforming the form to page). On RTC the dialog test runs approx. 3 times slower!