Description
My application uses protobufs that are dominated by a large number (10k-100k) of numerical values (predominately, double). Validating that every value is finite via protovalidate-cc ((buf.validate.field).double.finite = true) takes nearly 100ms on my system. It looks like a change to use a native, non-CEL, function that calls std::isfinite in a for-loop for a repeated double field is straightforward within protovalidate-cc's well-structured code-base. Indeed, I've experimented with this change within protovalidate-cc, and my runtime improves dramatically, dropping my 100ms runtime to about 700us. This is game changing for me, since the 100ms runtime makes protovalidate-cc unusable in my real-time robotics application. 700us is no sweat.
The change is so straightforward that it feels like an explicit choice to not do this, and lean heavily into CEL, even for simple numerical tests, for the sake of simplicity and uniformity. Is this the case? Would this project welcome patches that move operations out of CEL and into native tests? Either way, thank you for sharing this great project.
Description
My application uses protobufs that are dominated by a large number (10k-100k) of numerical values (predominately,
double). Validating that every value is finite via protovalidate-cc ((buf.validate.field).double.finite = true) takes nearly 100ms on my system. It looks like a change to use a native, non-CEL, function that callsstd::isfinitein afor-loop for a repeateddoublefield is straightforward within protovalidate-cc's well-structured code-base. Indeed, I've experimented with this change within protovalidate-cc, and my runtime improves dramatically, dropping my 100ms runtime to about 700us. This is game changing for me, since the 100ms runtime makes protovalidate-cc unusable in my real-time robotics application. 700us is no sweat.The change is so straightforward that it feels like an explicit choice to not do this, and lean heavily into CEL, even for simple numerical tests, for the sake of simplicity and uniformity. Is this the case? Would this project welcome patches that move operations out of CEL and into native tests? Either way, thank you for sharing this great project.