<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so the simple O(1) split would produce three submaps, the middle one having only one element. This operation would not be very parallelization-friendly.<br></blockquote><div><br></div><div>Actually, I'm perfectly happy with that in this case! </div>


<div><ul><li>A decent work-stealing system can tolerate a fairly large number of excessively small, trivial computations. It's having <b><i>only</i></b> those that's a big problem.  (Which is what you often get if your parallel container ops spawn a task per element.)</li>


<li>Since Maps support O(1) size, the consumer of the split-up-map could choose to sequentially execute the singleton maps if desired.</li></ul><div>Personally, I'm most interested in set-like operations and don't need any order guarantees.  But that's another dimension in which one could chop up the API...</div>


<div><br></div><div>Maybe this does deserve its own module in the namespace, and maybe its own package, as Edward suggested.</div><div><br></div><div>  -Ryan</div><div><br></div><div><br></div></div></div></div></div>