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
In working with this package and looking for performance optimisations one of the possible bottlenecks we identified was that queries were first read into a map, be that FluxRecord or GenericMap after which they'd be converted into the supplied struct through the FromMap trait. While at the moment we wouldn't have a need for optimising this last bit of performance, we thought it might be worthwhile to share the thinking we've done on this so far. Both to get the ball rolling should the need for this last bit of performance arise or for others to pick up if they should feel like it.
For simplicity we'll assume the following query and struct:
While the implementation of Builder isn't the easiest, I think it wouldn't be that difficult to see where it can be generalised in terms of the struct fields.
To maintain compatibility you'd probably want an impl RowBuilder<FluxRecord> as well. I hope you find this approach constructive.
The text was updated successfully, but these errors were encountered:
On second thought this is pretty similar to what csv and serde are already doing. It'd probably be easier to lean on them instead of going about it alone. Though I do need to do some more reading to fully understand how csv and serde interact
In working with this package and looking for performance optimisations one of the possible bottlenecks we identified was that queries were first read into a map, be that
FluxRecord
orGenericMap
after which they'd be converted into the suppliedstruct
through theFromMap
trait. While at the moment we wouldn't have a need for optimising this last bit of performance, we thought it might be worthwhile to share the thinking we've done on this so far. Both to get the ball rolling should the need for this last bit of performance arise or for others to pick up if they should feel like it.For simplicity we'll assume the following query and struct:
The main goal is for the
impl FallibleIterator for QueryTableResult
to have a genericItem
. The way I'd go about it is by defining aand adding a
then the trick would be to define the
#[derive(Buildable)]
to add to ourstruct Row
.struct QueryTableResult
would then contain theimpl RowBuilder
.An implementation of
RowBuilder
for ourRow
would be:While the implementation of
Builder
isn't the easiest, I think it wouldn't be that difficult to see where it can be generalised in terms of the struct fields.To maintain compatibility you'd probably want an
impl RowBuilder<FluxRecord>
as well. I hope you find this approach constructive.The text was updated successfully, but these errors were encountered: