>> Instead (<! channel) (>! channel val) you do (<! (take! channel)) (<! (put channel val)).
That would make channels even slower, not to mention that it would probably completely break interaction with alts!. I'm not saying it absolutely couldn't be done, I just don't see a need for it. core.async is a CSP library. Now any performance optimizations to the lib are always welcome, but such changes shouldn't change the semantics of the library, and definitely shouldn't make performance worse in the common case. Timothy On Thu, Mar 13, 2014 at 3:57 AM, Jörg Winter <jwin1...@gmail.com> wrote: > You could also try out: > http://docs.paralleluniverse.co/pulsar/ > > > Am Dienstag, 11. März 2014 18:39:54 UTC+1 schrieb Эльдар Габдуллин: > >> 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. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
