Speed up the reflection#537
Conversation
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
|
Any tests that proved it actually improved it? |
|
@ZXShady , I have done a lot of profiling with Clang's The bottleneck isn't the reflection, it is generating the code for serialization and deserialization. We have already done a lot of optimization there, such as implementing a non-recursive tuple (rfl::Tuple) class rather than using the recursively implemented std::tuple. glaze does something similar, but they use a third-party tuple implementation rather than their own. Same idea nonetheless. However, I liked your idea of nesting the field extractions as a binary tree of constexpr if. It's easy to do and a clear win for larger structs. So I thought why not do it. |
|
@ZXShady , I will show you what I mean. This is the profile for the test for the README function. The total duration of the struct reflection is about 92 milliseconds, or less than 5% of the total compile time.
|
|
@ZXShady , here is the profile for the This is obviously a construed example that is unlikely to ever occur in the real world. If you are going to have structs with that many fields, the fields are probably going to be more complex than just floats. In other words, this is probably the greatest share of time spent on struct reflection in any of our tests.
But even for this construed example...we talking about 20-25% of the total compile time. If you can cut that in half, you will have reduced the overall compile time by 10-12% or so. But this is really an upper bound...in the real world it's going to be a lot less. |
|
I wish github mobile actually worked and I got notifications when you pinged me..... |


No description provided.