RowBuffer is currently one of the most frequently accessed structures, and, unfortunately, it is pretty memory-sparse, which hurts performance.
We could make a really crazy thing where the underlying storage of a RowBuffer were just two arrays, of row type (byte[]) and the content (ProtoMessage[]). While the memory layout would not be perfect (type and message pointer will not be next to each other), we would eliminate 1. array of pointers to rows (Nx4B) 2. object headers of RdfStreamRow
- original: 4 * n [row array] + (12 [OH] + 4 [pointer] + 1 [byte] + 7 [alignment]) * n = 28n
- proposed: 4 * n [pointers] + 1 * n [bytes] = 5n
where n is the number of rows in the buffer. I'm not counting the overhead for the array header (it's constant).
This would not do anything if we were using allocation-free parsing (#371), but could help a tiny bit with serialization.
Because of that, I would really prioritize #371 first, and then investigate this one.
RowBuffer is currently one of the most frequently accessed structures, and, unfortunately, it is pretty memory-sparse, which hurts performance.
We could make a really crazy thing where the underlying storage of a RowBuffer were just two arrays, of row type (byte[]) and the content (ProtoMessage[]). While the memory layout would not be perfect (type and message pointer will not be next to each other), we would eliminate 1. array of pointers to rows (Nx4B) 2. object headers of RdfStreamRow
where n is the number of rows in the buffer. I'm not counting the overhead for the array header (it's constant).
This would not do anything if we were using allocation-free parsing (#371), but could help a tiny bit with serialization.
Because of that, I would really prioritize #371 first, and then investigate this one.