I've also ran into situations as well where the context switching of the
thread pool is prohibitive. I swapped out the thread pool with a single
threaded executor and saw a big speed improvement. The downside is that
you can not specify what thread pool a go block should be ran on. This
means I had to hack the global thread pool like so:
;; hack for using a single thread
(in-ns 'clojure.core.async.impl.exec.threadpool)
(defonce thread-factory (conc/counted-thread-factory
"clj-sim-dispatch-%d" false))
(defn sim-executor []
(Executors/newFixedThreadPool 1 thread-factory))
(defonce single-tp (sim-executor))
(def the-executor single-tp)
(in-ns 'my-ns)
I'd be curious to see if this hack gives you similar performance
benefits as your promise fork. It would be nice if you could pass in an
executor to a go-block to override the default global one to
accommodate these different use cases. This would be similar to how you
can now control the executors for futures.
-Ben
On 3/11/14, 11:39 AM, Эльдар Габдуллин wrote:
Each go block is executed via thread pool. On a channel side,
producers and consumers are also decoupled.
Such decoupling costs around 10-20 us per async operation. For the
cases when your async
values are immediately available (e.g. from cache), or when you
designed an async
API just because your operations may block for a long but not
necessary do, those are huge numbers.
For example, I recently worked on a dependency injection container
<https://github.com/dar-clojure/core> which supports async computations.
Asynchrony in one place means that all you API will be async
everywhere. Natural way to go with implementation is to just
wrap everything in a go block. However, after doing that I found that
container became 50 times slower. 5 us overhead for a
typical task turned into 250 us.
As a solution I forked
<https://github.com/dar-clojure/async> core.async and replaced
channels with lightweight promises and removed thread pool dispatch from
everywhere. Now async container implementation is only 5 times slower
than its sync version, which is probably acceptable.
I'd like to hear what others think about this issue, especially
members of the core team.
--
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
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
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
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
