Replace getproperty
parameter data access with typed getindex
to improve inference
#9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
getproperty
syntax to access the data in a parameter, e.g.f.groups[:POINT].RATE
caused type instability (due to the parameterdata possibly being any number of types, String, Vector{Float32}, Int16,
etc). This type instability also affected accessing
Group
fields usingthe dot syntax. (
getfield
would not have been affected.)The root cause of the type instability is that the type
of the
params
Dictionary in eachGroup
must be not fully concrete, since groups will have anynumber of parameters with different types. However, some types can be
assumed based on the group/name (e.g. POINT:USED should always be an
integer). My solution is to add a typed
getindex
that type assertsthe return type:
f.groups[:POINT][Int, :USED]
. This solves the typeinstability, while maintaining the ability to access parameters even when
you don't know or care to assert the type:
f.groups[:POINT][:USED]
.This (and a few other inference related changes) is responsible for dramatically improving the "first run" time and reducing allocations as well.
Benchmarks: