viirya commented on PR #5765: URL: https://github.com/apache/datafusion-comet/pull/5765#issuecomment-5580198581
Thanks both. @comphead — extended to eleven shapes. The four additions each take a different recursion rather than just being more of the same, which is what makes them worth timing separately: | shape | why | time | |---|---|---| | `struct<a: int32, m: map<utf8, int32>>` | the struct branch recurses into the map specialization | 640 µs | | `array<array<int32>>` | the element is a list, so it reaches the vectorized leaf loop one level down | 1685 µs | | `map<utf8, struct<..>>` | a struct as the map value falls outside the key/value specializations | 13088 µs | | `array<struct<a: int32, m: map<..>>>` | three levels, so it goes through all of the above | 8542 µs | 8192 rows, Apple M4 Max. `map<utf8, struct>` turning out to be the slowest of all eleven is the kind of thing I wanted these to surface — the specialized key/value pairs cover a lot, and the shape just outside them is expensive. @sunchao — you are right about the skewed comment, and thanks for reading it against the implementation. It described a pass-per-element-position structure, which the current fallback does not have: it walks each row and slices one element at a time. I had written it from a change that is not on `main`. Corrected to describe the distribution rather than a pass structure: > `array<struct<..>>` where one row is far longer than the rest, so the element count is spread very unevenly across rows rather than uniformly. The per-element path slices and re-dispatches once per element, so a batch dominated by a single long list has the same total work in a very different distribution, which a uniform shape cannot show. Your point about the `array<int32>` versus `array<struct>` comparison is fair too — it moves dispatch and payload together, since the struct element carries an integer and a string against the primitive element's single integer, so it is not an isolated measure of dispatch overhead. I have noted that alongside the numbers rather than presenting the ratio as if it were. Agreed on scope as well: these are descriptive timings for these fixtures on one machine, non-null and ordinary UTF-8, and they do not establish null, collation or error-path parity. The value is as a fixed comparison point for later changes to the same kernel. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
