ZipOuterJoin should have a fast path for single chunks

[ritchie46]

Currently the TakeRandom traits are used, but this is expensive for the most common case, single chunks.

[marcvanheerden]

I'll pick this up if thats okay

[ritchie46]

Ah, yes! 🙂

[marcvanheerden]

Hi, @ritchie46 I attempted this by using .get_unchecked() directly on the chunked array when there is only one chunk.

marcvanheerden@71a1b34

This didn't improve the performance noticeably. I tested it out on an outer join of two 10mil row tables. Have I misunderstood the request?

[ritchie46]

The idea was to unpack to the underlaying PrimitiveArray instead of using the take_rand proxy.

We can get the PrimitiveArray like this: self.downcast_iter().next().unwrap();

[marcvanheerden]

I tried it in this commit on my fork: marcvanheerden@edcf5cd

Still not getting a measurable run time difference on the same two 10mil row tables. I used hyperfine for the measurement and the change is slower by 10ms on around 7s for the join. I think this is just noise and not an actual regression.

Let me know if I'm doing something wrong

[ritchie46]

@marcvanheerden I've left some comments that should help the performance.

[marcvanheerden]

Thanks for your help again, I've made the change here. Unforunately I'm not seeing a performance improvement.

If I'm reading these flamegraphs correctly it looks like:

1. The changes don't make a big difference
2. The piece we're working on is quite a small portion of the runtime overall so there isn't much time to be gained.

Here are the before and after flamegraphs.
Archive.zip

Let me know if I'm making a mistake or missing something.

Thanks

[ritchie46]

An outer join does also quite some work. Maybe should isolate the functionality we're benching?