-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve inferrabililty #36
Conversation
Inference loses track of `Tag` due to JuliaLang/julia#36454
src/files.jl
Outdated
@@ -86,6 +88,7 @@ function Base.read!(file::TiffFile, arr::AbstractArray) | |||
end | |||
end | |||
|
|||
# This is type-piracy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed this first by reading the code, but as I changed method dispatch I sometimes hit it in real life. I think it's pretty important to eliminate this before it becomes a FileIO default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack. Good catch. I need to just delete this method and figure out a different way to detect strided bilevel TIFFs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'm 99% sure replacing io with tf:TiffFile
would still work and fix the type piracy.
Having "finished" this, were I to do it over again I'd probably add a |
Thanks for taking the time to put this code base through the wringer! I didn't realize that So in that case, we could add an |
The compiler will specialize for each `N` in `Val{N}`, and so just loading images with different numbers of slice planes will require additional compilation. This adds to latency for no benefit, so it's best not to use `Val` this way. This throws in a few `@nospecialize` for a couple of other `Val` uses.
1b106b1
to
a93818a
Compare
Down to julia> @btime begin
TiffImages.save("/tmp/file.tiff", img)
imgs = TiffImages.load("/tmp/file.tiff")
end;
370.517 μs (545 allocations: 111.09 KiB) which is now getting into the territory of considerable improvement. I took the liberty of shifting you from |
Codecov Report
@@ Coverage Diff @@
## master #36 +/- ##
==========================================
+ Coverage 87.84% 88.15% +0.30%
==========================================
Files 12 12
Lines 543 557 +14
==========================================
+ Hits 477 491 +14
Misses 66 66
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with these changes now that we parameterize TiffFile on the stream type! Thanks @timholy.
Nice! Happy to update #35 after this merges |
julia> using TiffImages
[ Info: Precompiling TiffImages [731e570b-9d59-4bfa-96dc-6df516fadf69]
julia> @time TiffImages.load("/home/tlnagy/Downloads/Gcamp6F_BSA_60px_3_stack.ome.tif");
2.291251 seconds (3.37 M allocations: 664.546 MiB, 2.18% gc time)
julia> @time TiffImages.load("/home/tlnagy/Downloads/Gcamp6F_BSA_60px_3_stack.ome.tif");
0.739291 seconds (276.28 k allocations: 504.956 MiB, 2.49% gc time)
julia> using ImageMagick
julia> @time ImageMagick.load("/home/tlnagy/Downloads/Gcamp6F_BSA_60px_3_stack.ome.tif");
4.011342 seconds (2.70 M allocations: 1.540 GiB, 4.56% gc time)
julia> @time ImageMagick.load("/home/tlnagy/Downloads/Gcamp6F_BSA_60px_3_stack.ome.tif");
3.180862 seconds (6.72 k allocations: 1.408 GiB, 0.51% gc time) Faster on initial load and way faster on subsequent loads (~5x). Also way less memory usage. |
Thanks for merging! Note I didn't do anything to solve the piracy issue. Looking forward to seeing this in action! |
I am so glad to be making progress on moving away from ImageMagick! I'm impressed (and slightly puzzled) that the latency is already lower. That should improve even more with #35. |
fixes the issue brought up by @timholy in #36 (comment)
Fix over in #38. Added another test for this code branch because coverage was a little shallow 😅 |
fixes the issue brought up by @timholy in #36 (comment)
This makes the methods of this package less vulnerable to invalidation, should improve precompilability, and result in a small runtime performance improvement:
master
:This branch: