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.
