Bug 176320

Summary:

Non linear progress in open type dialog

Product:

[Eclipse Project] JDT

Reporter:

Philipe Mulet <philippe_mulet>

Component:

Core

Assignee:

Jerome Lanneluc <jerome_lanneluc>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

Keywords:

polish

Version:

3.3

Target Milestone:

3.3 M7

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Proposed fix	none

Description Philipe Mulet

2007-03-04 17:16:13 EST

Build 20070228

When migrating to latest SDK, I got it all reindexing the workspace due to index format change (ok). What striked me is that when opening the type dialog, it rendered indexing progress in a strange way. It rushed to 50%, while accumulating more indexing jobs. Then it processed them down to 0, and then filled the rest of the progress in half a second.

I think it should better deal with the situation where reindexing is occurring when reporting the progress, so it becomes more linear.

Comment 1 Jerome Lanneluc

2007-03-05 02:11:06 EST

Unfortunately, it is impossible to know in advance how many jobs are going to be processed, since in the situation you observed, more jobs are added as the progress is shown (one job can expand in multiple jobs, think in the case of a project indexing job that expands in multiple compilation unit indexing jobs).

When implementing this, I remember that I tried to make it logorithmic, so it unexpected that you see it rush to 50%. It should go fast first, then slower and slower up to 50%.

We might want to fine tune this algorithm more.

Comment 2 Philipe Mulet

2007-03-05 03:30:19 EST

Can't we know upfront that there is indexing in progress, and then tune the search progress 80/20 or 90/10, instead of 50/50 ?

Comment 3 Jerome Lanneluc

2007-03-05 03:39:40 EST

Yes, it should be possible to look at the job queue, and if not empty, change the sub-progress monitor to use 90%.

Comment 4 Jerome Lanneluc

2007-03-08 11:21:35 EST

Thinking more about it, I'm not sure it is a good idea to have the progress be 90/10. Consider the following scenario:
1. There are 2 jobs in the queue
2. Open Type dialog is opened
3. After the 2 jobs have been processed, the progress is at 90% after 0.2 second (assuming 0.1 second per job)
4. BUT the last processed job has added 1000 more jobs in the queue
The progress is going to remain at 90% (ie. close to the end) for the time of the 1000 jobs processing (roughly 100 seconds).

At least if we leave the 50/50 ratio, even if there is 1000 jobs to process, it doesn't appear the we are close to the end.

Comment 5 Jerome Lanneluc

2007-03-30 11:01:05 EDT

A better implementation would be to not have the totalWork of the indexing subprogress be the number of jobs in the queue, but rather a fixed amount (let's say 1000), then report progress of 1 per job. If more jobs are added, the progress per job would be decrease. This way we can have a 80/20 ratio.

Comment 6 Jerome Lanneluc

2007-04-02 07:10:34 EDT

Created attachment 62648 [details]
Proposed fix

Comment 7 Jerome Lanneluc

2007-04-02 07:34:04 EDT

Fix released for 3.3M7 in HEAD.

However, note that because of bug 180470, the total progress given to search in the Open Type dialog is 10%. So you won't see much difference until bug 180470 is fixed.

Comment 8 David Audel

2007-04-27 07:03:38 EDT

Verified for 3.3 M7 using build I20070427-0010.