Varying length candidates vs. length-sensitive OpenCL formats. Decrease LWS?

Just brainstorming: These are vague ideas/theories but I'd appreciate comments before I waste a lot of time to no avail. Maybe what I say here doesn't even make sense - please correct me.

I was thinking about RAR-opencl and md5crypt-opencl but this applies to some others as well. RAR is among the most length-sensitive formats of them all, the penalty for longer candidates is huge - if you get 62 Kp/s for length 4 you may get 36 Kp/s for length 16. To add insult to injury, if 127 candidates of a local group of 128 is length 4 and the single last one is length 16, you'll obviously get the lower speed for all of them - at best. Our current kernel mitigates the problem as good as it can for not getting even worse penalties from crazy lock-stepping but at best the time to calculate a local size batch of candidates is dictated by the longest one(s).

What if we simply decreased the local group size for such batches? Assuming the penalty for the lower LWS itself is less than the penalty for running a larger batch with non-uniform lengths, wouldn't we get a net gain? I have a hard time picturing it all in my head, maybe I simply need to test it.

For md5crypt, it's less complex: If we have uniform lengths within the local group, we get a more optimized code path. Assuming auto-tune found a local size of 256 is fastest [n.b. auto-tune runs uniform batches], 128, 64 or even 32 might be nearly as fast but obviously have a better chance of being uniform.

Assuming that my reasoning is even correct, next question is how to handle it: One option is to flag these formats as FMT_UNIFORM_LENGTH (or whatever name) which could hint the auto-tune code to slightly prefer a lower LWS (often leading to a higher GWS to compensate).
Another option is to have set_key track whether current batch is uniform or not. Very little overhead. Then in crypt_all we could lower LWS for such batches, but in this case it might not be safe to assume we can bump GWS accordingly (maybe it was limited by something else, like GPU memory).
We could obviously do both: Auto-tune for a "low" and a "high" local size of LWS/GWS pairs, and remember both. When a non-uniform batch comes up, use the lower LWS with its companion GWS.

The issue discusses RAR-opencl and md5crypt-opencl, along with set_key, crypt_all, and auto-tune, but names no files or tests. Begin by measuring uniform and non-uniform candidate batches at different local work sizes, then determine whether the proposed tuning changes produce a reproducible net gain.