 <p>With this type of problem getting the time spent splitting the data up for parallel processing and then putting it back together to be less than the time to process it in a sequence can be tricky. </p> <p>In the problem above, if i'm interpreting it correctly you are generating two sequences of data, each in parallel. So these sequences can't communicate with each other during this process to see if they have a later date. Once all of the data for both sequences is finished then you form it into a map. and then split that map back into a sequence and start processing it. </p> <p>The first pair of dates, (first loc) and (first mob), will be sitting for quite a while before they can be compared to see if they should go into the final result. so the best speedup may come from simply removing the call to zipmap.</p> <p><code>time/after?</code> is very fast so you will <b>almost certainly loose time</b> by calling pmap here, though it's good to know how to do it anyway. You can get aroung the inability of the anonymous function macro to handle nested anonymous functions by making one of tham a call to <code>fn</code> like so:</p> <pre><code>(keep (fn [x] (when (pmap #(later-date? (second x) after) zip)) [(first %) (second %)]) </code></pre> <p>Another approach is to </p> <ol> <li>break it into partitions, </li> <li>do all the processing on each partition, and </li> <li>merge them back together. </li> </ol> <p>Then <b>adjust the partition size until you see a benefit</b> over the splitting costs. </p> <p>This has been discussed <a href="http://stackoverflow.com/questions/1702705/how-to-efficiently-apply-a-medium-weight-function-in-parallel">here</a>, and <a href="http://stackoverflow.com/questions/2103599/better-alternative-to-pmap-in-clojure-for-parallelizing-moderately-inexpensive-f">here</a></p>