Ticket #90 (closed enhancement: fixed)
Generic speed meter
| Reported by: | Joel | Owned by: | Joel |
|---|---|---|---|
| Priority: | trivial | Milestone: | Eraser 6.1/6.2 |
| Component: | User Interface (UX) | Version: | |
| Keywords: | Cc: | ||
| Processor Architecture: | Blocked By: | ||
| Blocking: | #284 | Operating System: |
Description
The DirectExecutor? code needs a generic way of measuring speed and amount of time required to complete a task, so that the speed and progress measurements can be used for erasing any kinds of stuff.
Blocking
| Id | Summary | Milestone |
|---|---|---|
| #90 | └ Generic speed meter | Eraser 6.1/6.2 |
| #284 | └ Eraser.Util rewrite | Eraser 6.1/6.2 |
| #275 | └ Code Review | Eraser 6.1/6.2 |
| #262 | └ Localise the Util.Native and Util libraries | Eraser 6.1/6.2 |
Blocked by
| Id | Summary | Milestone |
|---|---|---|
| #90 | └ Generic speed meter | Eraser 6.1/6.2 |
Change History
comment:4 Changed 4 years ago by Joel
Perhaps even store the previous execution state so that when new event handlers arrive they can get cached information? Perhaps this can help with #173
comment:6 Changed 4 years ago by Joel
Change the TaskProgressManager? constructor to not depend on the tasks being registered to give the total data size as the data may not be completely present for analysis at the point of construction (e.g. in DirectExecutor?.Main)
comment:7 Changed 4 years ago by Joel
- Milestone changed from Eraser 6.0.7 to Eraser 6.1/6.2
- Calculate in terms of work units
- Start/stop functions to sample work units per sec
- Calculate end time
comment:8 Changed 4 years ago by Joel
Also, it'll be good to unify how progress feedback is given to interested clients. Perhaps, follow an interface or a particular callback prototype that's defined in the speed meter class?
comment:9 Changed 3 years ago by Joel
The meter will need to take into account weighted progress steps. Also define a standard callback function for progress.
comment:10 Changed 3 years ago by Joel
The speed meter must also be multithreaded!
comment:12 Changed 3 years ago by Joel
See the source:/branches/eraser6/SpeedMeter branch.
comment:13 Changed 3 years ago by Joel
As of now, the summary:
Currently proposed design achieves:
- storing the previous progress value; the progress is stored together with the Task and Targets; progress information is always available and independent of waiting for a progress event to be fired.
- task progress is only dependent on Total and Complete values (for ProgressManager class), or chained progress managers (for ChainedProgressManager derivatives SteppedProgressManager and ParallelProgressManager)
- work units are the only form of progress computation (unit agnostic)
- estimated completion time possible based on the Speed of the task over the time taken to complete the current amount of work
- the SteppedProgressManager allows us to compute overall progress based on steps competed
It does not/is not:
- allow sampling of speed
- unify the way progress is reported to clients
- thread-safe
comment:14 Changed 3 years ago by Joel
As of r1510 the Chained progress managers are thread-safe.
The next step in completing this ticket will be to use the ProgressManager? classes across the entire Eraser solution. Current candidates:
- BlackBox branch: The Uploader
- Trunk: Updater
comment:16 Changed 3 years ago by Joel
The Updater code now uses the ProgressManager? classes for progress calculations since r1511
comment:17 Changed 3 years ago by Joel
There's a standard method of broadcasting the events to interested listeners since r1512.
comment:18 Changed 3 years ago by Joel
- Status changed from accepted to closed
- Resolution set to fixed
Branch merged in r1515. Task has been completed.
Some progress made in r804