Performance issue JProgressBar

Classic Servoy
1

I don’t know if it is a bug, but I noticed that my performance is decreased enormously using the JProgressBar in combination with application.updateUI()

See the following code. It loops through a foundset of 78 records and for each record, my progressbar is updated:

var _time_from = application.getTimeStamp()
application.output('Start ' + _foundset.getSize() + ' counts; time = ' + _time_from )

globals.svy_nav_progress_init(_foundset.getSize());

for (var i = 1; i <= _foundset.getSize(); i++)
{
	globals.svy_nav_progress_update(i)
}

globals.svy_nav_progress_completed();

var _time_till = application.getTimeStamp()
application.output('End   ' + _foundset.getSize() + ' counts; time = ' + _time_till )

var _ms = _time_till.getTime() - _time_from.getTime()

application.output('Nr of milliseconds = ' + _ms)

The svy_nav_progress_update() method looks like this:

var _value = arguments[0];

if (_value == undefined)
{
	return false
}

forms.svy_nav_lfo_buttonbar_browser.elements.svy_nav_Progressbar.value = _value
application.updateUI(forms.svy_nav_lfo_buttonbar_browser.elements.svy_nav_Progressbar)

So what you see is that the progressbar is updated with de value given as argument.

You can see that the application.updateUI only has to refresh the argument given as parameter, which is my JProgressBar

The result of the script is as follows:

Start 78 counts; time = Wed Jan 30 15:15:18 CET 2008
End 78 counts; time = Wed Jan 30 15:15:30 CET 2008
Nr of milliseconds = 11940

That is quite long (almost 12 seconds!) for a loop that only counts from 1 till 78.

Now I remove the application.updateUI() line and then the result is as follows:

Start 78 counts; time = Wed Jan 30 15:26:46 CET 2008
End 78 counts; time = Wed Jan 30 15:26:46 CET 2008
Nr of milliseconds = 343

So when updating the progressbar on each iteration makes the script almost 35 times slower!

Is there an explanation for that?

2

Maybe your solution is different that mine, but I haven’t found I’ve needed to use application.updateUI with our progress bar. However, I do think we add an application.sleep(105) after updating it, so that might be accomplishing the same thing. I think the problem you are experiencing is that by and large any sort of GUI interaction is a slow event as far as things go.

The way we get around this in our solution is not updating after every record, but rather after every 5/10/25/100 iterations depending on the size of the set.

3

updateUI does make a method run significantly slower because of screen redraws. If you don’t call it, the progress might not display nicely.

I usually call updateUI every x iterations only for that reason.