-
Notifications
You must be signed in to change notification settings - Fork 608
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
perf: file read performance -- double reads, extra copies
Doing some benchmarking and adding extra LoggedTimer instrumentation (included in another PR), I discovered that quite frequently, the in-memory flavor of ImageBuf was reading its image multiple times -- once upon construction, and then again upon later calls to read(), even though the latter should have taken early outs when the read was unnecessary. So I put some additional mechanism for the IB to internally know if it read the pixels from disk into the buffer, and more effectively make calls to IB.read() be a no-op. To help facilitate this, I also clarified in the docs that read() should not be used to move an already-read image to a different subimage or MIP level or a different data type -- reset() really should be used for that purpose. (I don't know that anybody ever relied on read() to do reset's job, but assuming that they won't helps eliminate some tricky cases.) Also, I noticed that inside ImageInput::read_image(), depending on whether or not a data type conversion is needed, it can either read directly into the user's buffer, or must read the native data into a temp buffer and subsequently do a copy-and-type-convert into the user's buffer. The latter is obviously more expensive. The direct read approach was used when the user asked for no type conversion (just to receive the native data type in the fiel), but it neglected to take the same shortcut if the user asked for an explicit type conversion, but it just so happened that the requested type was the type in the file. Additional changes: The evaluation of whether the buffer was contiguous (for various shortcuts) only applied to LOCALBUFFER style storage, not APPBUFFER. Fixing these two problems dramatically speeds up some reads. A benchmark I was looking at where it reads a 10k x 10k uint8 uncompressed TIFF file into an ImageBuf while requesting uint8 data went from (timings on my laptop): function calls total IB::read 2 0.505s (avg 0.25s) II::read_image 2 0.478s (avg 0.24s) to: IB::read 1 0.172s (avg 0.17s) II::read_image 1 0.172s (avg 0.17s) So almost 3x faster. Most of which was due doing 2 reads instead of 1, but still each individual read improved from 0.25s to 0.17s because of the fix that lets us avoid the unnecessary buffer copies. Grain of salt: this was a very large image, and it was stored uncompressed (so NO decompression that can sometimes be a significant amount of overhead), so you may not see this much improvement in real world scenarios. This is only scratching the surface, I believe there are lots of other areas to optimize more carefully. Signed-off-by: Larry Gritz <lg@larrygritz.com>
- Loading branch information
Showing
5 changed files
with
92 additions
and
42 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters