Loading might be a little too lazy, leading to long access times #4
Labels
Comments
tlnagy
added a commit
that referenced
this issue
Mar 24, 2020
This has a pretty massive effect on performance. Accessing a single pixel went from ~20ns to 8ns with this change. Only 5x slower than no lazy transformation at all. Working on #4
tlnagy
added a commit
that referenced
this issue
Jan 1, 2021
this implementation uses the idea from #4 where load the raw data, lazily apply transformations and then eagerly realize the final version to reduce the access-time penalty. It might be possible to refactor this code a bit further to dispatch on the IFD layout so that I can avoid a lot of these if/else statements and off load them to compile time.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My current strategy has been to store the data in-memory exactly as on disk and lazily transform it on access to the expected dimensions and shape. While this leads to great loading times, access is quite slow (~100-150x slower than
ImageMagick.jl). Alternatively, I could try to create both the target image location and a buffer that is sized to the maximum number of bytes expected. I could read into this buffer, apply transforms lazily, and then save into the target (realizing the transforms).The text was updated successfully, but these errors were encountered: