|
> [ Hope I am not coming across as too negative, but since you put it in a paper and published it I think it is fair to do some peer review ] No, not at all, your feedback is highly appreciated!
BTW, the paper is a preprint, it is currently under review. - I fully agree with the O(N) vs O(1) issue in the evalPartialDerivative. Also, an optimization possibility I considered is to replace string-valued variable names like "Y" by integers, but this adds some bookkeeping-burden for a creator of a message that works in a programming language other than c++ (for which we do not provide convenience methods for building messages) - I agree with the auto vs (const) auto& point you raised. However, some cap'n proto types (readers / builders) are copyable types ("handles"), hence they should be using with auto. (And, sometimes, the compiler can do better optimizations when you've passed objects (of small size) by value rather than ref, but this might be different for each specific case; one would have to benchmark.) Regarding expression: "P-10+q^2":
The string encoding is much shorter indeed, and is an alternative way.
However,
- double values potentially lose precision in a string representation (btw, also this "JSON bridge" I mentioned earlier suffers from this problem) and possibly take up more space than 8 bytes.
- the schema also serves as the grammar of the message format; is a compact "manual", in that (almost) everything that can be expressed using the schema will be "valid" and accepted by the interpreter.
If one encodes a string, one has to define this grammar separately (one has to define what is a 'valid' string and what not). Adopting this schema-based solution saved us work.
- there are typically more objects in a message ("advertisement"), so the string would have to be augmented with information about what it represents in the message.
- also: having a schema-based solution helped us in designing the message format (the types defined in the schema let you think in a more abstract way about the message format), and provides evolvability. Hence, there were certain motivations for choosing this approach that are unrelated to space (bytesize) or runtime performance. |