Community
Participate
Working Groups
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.
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.
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 ?
Yes, it should be possible to look at the job queue, and if not empty, change the sub-progress monitor to use 90%.
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.
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.
Created attachment 62648 [details] Proposed fix
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.
Verified for 3.3 M7 using build I20070427-0010.
