user=> (def dummy-times [3000 10 9 8 7 6 5 4 3 2 1]) > #'user/dummy-times > user=> (time (pmap #(do (Thread/sleep %) %) dummy-times)) > "Elapsed time: 16.213366 msecs" > (3000 10 9 8 7 6 5 4 3 2 1) ;;here you waited 3s before sleeping for > 0.01 s > user=> (time (pool-map #(do (Thread/sleep %) %) dummy-times)) > "Elapsed time: 21.004979 msecs" > (10 9 8 7 6 5 4 3 2 1 3000) ;;here you've not waited at all - sleeping > for 3s finished last and is last > user=> (time (pool-map1 #(do (Thread/sleep %) %) dummy-times)) > "Elapsed time: 3008.174631 msecs" ;;non-lazy? > (3000 10 9 8 7 6 5 4 3 2 1) ;;again your version will wait for the first > item to finish before proceeding >
This only demonstrates a special case where there is an advantage. What about the scenario with (def dummy-times [3000 3000 3000 3000 3000 3000 3000 10 9 8 7 6 5 4 3 2 1]) Now all your threads are busy processing the long tasks, the shorter ones waiting patiently at the end of the queue. Nothing gained. > hmmm...so the completion service is useless? It can't be... You say > that'You can't know which tasks will take less time until they are already > done' but the way I see it you don't need to...all you need to know at any > given time is whether a or some futures have completed. > The tasks are waiting in the queue, they are not being executed at all. And the time they spend waiting cannot theoretically be a function of the time they will take to execute, once they get their chance. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
