You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a bunch of senarios, in which is should be possible to know at compile time if an exception will be thrown. (especially if we exclude unrecoverable externally triggged exceptions like out of memory).
E.g. if the code is inlined to only builtin's / LLVM intrinsics,
and there is no exception present in the code.
(maybe there could be for different iinput types, but we specialized on that so those go away).
Right now, even in the most obvious case, the compiler can't tell.
So it includes all this overhead to be ready to catch exception.
Example:
julia> function danger()
1.0
end
danger (generic function with 1 method)
julia> function safe()
try
1.0
catch
rethrow()
end
end
safe (generic function with 1 method)
julia> @btime safe()
17.163 ns (0 allocations: 0 bytes)
1.0
julia> @btime danger()
0.031 ns (0 allocations: 0 bytes)
1.0
There are a bunch of senarios, in which is should be possible to know at compile time if an exception will be thrown. (especially if we exclude unrecoverable externally triggged exceptions like out of memory).
E.g. if the code is inlined to only builtin's / LLVM intrinsics,
and there is no exception present in the code.
(maybe there could be for different iinput types, but we specialized on that so those go away).
Right now, even in the most obvious case, the compiler can't tell.
So it includes all this overhead to be ready to catch exception.
Example:
Realistic case:
JuliaDiff/ChainRulesCore.jl#82
The text was updated successfully, but these errors were encountered: