[ntuple] Simplify RNTuple::Streamer()
#16956
Conversation
This makes the writing and reading paths symmetric.
| auto expectedChecksum = XXH3_64bits(buf.Buffer() + offCkData, lenCkData); | ||
| auto offCkData = buf.Length() + sizeof(UInt_t) + sizeof(Version_t); | ||
| buf.ReadClassBuffer(RNTuple::Class(), this); | ||
| std::uint64_t expectedChecksum = XXH3_64bits(buf.Buffer() + offCkData, buf.Length() - offCkData); |
There was a problem hiding this comment.
So, we are assuming that (essentially) bcnt is the same as buf.Length(). Is this always true?
There was a problem hiding this comment.
Yes, somewhat: From my understanding, buf.Length() is essentially the current offset in buf. buf.Length() - offCkData with offCkData = buf.Length() + sizeof(UInt_t) + sizeof(Version_t) is therefore the number of processed bytes after the version (which is according to bcnt).
For comparison with the old version, note that lenStrip = sizeof(Version_t), which was the "relative offset" of the class buffer, while offCkData is the absolute offset in buf. See also the writing code path for the symmetry mentioned in the commit message.
There was a problem hiding this comment.
bcnt is the same as buf.Length(). Is this always true?
With an offset. buf.Length() is usually already non-zero at the start of a ::Streamer function.
bcnt is the number of bytes written for an object, including the version tag.
with
offCkData = buf.Length() + sizeof(UInt_t) + sizeof(Version_t)
has 2 caveats. In this expression buf.Length() is captured/recorded at the start of the ::Streamer function.
and the sizeof(Version_t) part is valid only for 'versioned classes`. For unversioned class were record both a marker (4 bytes with the value 0) and the checksum (another 4 bytes).
For RNTuple::Streamer, we know RNTuple is versioned and thus the calculation is correct.
Test Results 18 files 18 suites 4d 7h 28m 30s ⏱️ Results for commit b8d5e81. |
3 participants
This makes the writing and reading paths symmetric.