My container benchmarks showed up to 3 times improvement after that hack.

вторник, 11 марта 2014 г., 22:29:49 UTC+4 пользователь Ben Mabey написал:
>
>  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 clo...@googlegroups.com <javascript:>
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com <javascript:>
> 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+u...@googlegroups.com <javascript:>.
> 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.

Reply via email to