Description
What problem does this solve or what need does it fill?
Being able to access &(mut) dyn Reflect
fields from a larger dyn Reflect
via GetPath
is a very nice QOL option when loading scenes or just looking for a runtime reflection. However, repeatedly calling it's functions with the same string is wasteful as it re-parses the same string at every call.
What solution would you like?
It'd be ideal to have alternative APIs for parsing a field path ahead of time, and just using the parsed token stream or access-list.
Ideally this would also look up type registrations, possibly using static type information (#4042) to look up field numbers instead of using string based lookups to help further cut down on string operations on this fast-path.
What alternative(s) have you considered?
- Manually implementing a token-stream based equivalent to
path
,path_mut
,get_path
, andget_path_mut
. This would work for this one use case, but wouldn't be generically available as a fast-path for other use cases. - Pseudo-JIT compilation for creating runtime lenses for extracting references for a given type. This would probably be the most efficient way to do so, but also the most complex.
Additional context
This is an optional, but highly recommended optimization for #4026 to enable faster application of animated values.
The current code already tokenizes individual parts of the path. We'd just need to decouple this into a separate 'static
token stream that can be used as an alternative input.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status