Ticket #1176 (closed task: fixed)
Opened 2012-05-14T14:28:42-05:00
Last modified 2014-05-18T17:41:08-05:00
OPS speed baseline
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: | imagej2-b11-docs |
| Component: | ImgLib2 OPS | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1343 |
Description (last modified by bdezonia)
Here are some statistics of a speed test I ran with OPS shortly before beta 1. Check later as code changes how these results hold up.
Take a 1024 x 1024 image 8 bit image. Run Process > Math > Set and choose a value like 58. Time the assigner.assign() call.
On Barry's mac:
Slices, seconds
1, 0.112
5, 0.222
20, 0.808
35, 1.506
50, 2.013
65, 2.520
Change History
comment:1 Changed 2012-05-14T14:30:52-05:00 by bdezonia
- Description modified
comment:3 Changed 2012-07-17T15:24:40-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0
comment:4 Changed 2012-07-17T15:36:10-05:00 by bdezonia
- Milestone changed from imagej-2.0.0 to imagej-2.0.0-beta4
comment:6 Changed 2012-09-06T16:58:20-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5
comment:7 Changed 2012-10-15T12:32:13-05:00 by bdezonia
Retested very shortly before beta 5. Results are virtually unchanged. This is good news as some changes were made to OPS that I expected would slow things down.
comment:8 Changed 2013-01-22T15:18:05-06:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imagej2-unscheduled
comment:9 Changed 2013-04-15T10:25:49-05:00 by curtis
- Milestone changed from imagej2-unscheduled to imagej2-b11-docs
comment:10 Changed 2014-05-18T17:41:08-05:00 by curtis
- Status changed from new to closed
- Resolution set to fixed
The new ImageJ OPS project, intended to fully replace ImgLib2 OPS and SciJava OPS, has already done a lot of benchmarking. The flexible approach of ImageJ OPS allows ops to be multithreaded in very configurable and extensible ways. So I'd say we are really good to go from a performance perspective.
Note that hacking the number of threads allocated to 1 in ImageAssignment you can see that the multithreaded algorithm is 33% faster when it is using 2 threads instead of one.