Dunno how CLJS compares with CLJ WRT to this, but reading about how Clojure gains performance under the covers (and exposes these fns to use) is illuminating:
http://clojure.org/transients Jamie On Feb 10, 2015, at 12:49 PM, Gary Trakhman <[email protected]> wrote: > Yea, I think the general clojure advice has been to not early-optimize, much > work has been done to make the immutable data structures as fast as possible, > though I'm not sure where the CLJS ones are at perf-wise these days. > > If you ever reach a bottleneck in your app, it should be relatively easier > and less of a maintenance headache to make a fast/mutable/isolated > implementation compared to the cost of having to decouple mutable code after > it's already been written. > > In terms of the performance of immutable data structures, you'll always be > creating more garbage than a mutable bash-in-place version, so that might > dominate your performance for different types of workloads. > > On Tue Feb 10 2015 at 11:34:06 AM Marc Fawzi <[email protected]> wrote: > Answering my question with potential blind spots: > > The time it takes to populate data into an immutable tree (say an interval > tree data structure or whatever kind) and the cost of updates to that > immutable structure may be higher than the cost of copying. > > So I'm leaning toward the belief that immutable data structures help make > concurrency simpler and easier to debug but they may actually be less > performant than the mutable approach, and that's true either depending on the > type of data structure or always... Have not done the detailed thinking or > benchmarking... But I feel like I answered my own question in that > immutability is simply a basic requirement for functional programming but > while it makes concurrency easier even in single thread environments with > async loops running concurrently the impact on performance is likely negative. > > If that's wrong or partly wrong conclusion I would love to hear it and have > some examples. > > Thanks > > Marc > > > Sent from my iPhone > > On Feb 9, 2015, at 1:29 PM, Marc Fawzi <[email protected]> wrote: > >> by processes in my previous reply, I mean async data processing loops >> running concurrently, i.e. a function called via setImmediate that keeps >> calling itself, and where you can have multiple of those running >> concurrently and operating on the same data structure.... In JS world, we'd >> make copies of the data structure. In CLJS, there are immutable types and >> immutability is achieved without cloning... so all I'm looking for is an >> example of using immutability in CLJS as a performance advantage in such a >> scenario... is there one? >> >> On Mon, Feb 9, 2015 at 12:23 PM, Marc Fawzi <[email protected]> wrote: >> right, concurrent, omitting the web worker stuff which relies on messaging, >> >> I see improvements to code clarity and maintainability with core.async but >> I'm trying to find if CLJS' immutable data structures give it a performance >> advantage where normally expensive copying/cloning would be required for >> isolating the working memory of two or more processes >> >> >> On Mon, Feb 9, 2015 at 12:03 PM, Gary Trakhman <[email protected]> >> wrote: >> Core.async on clojurescript gives a huge advantage for concurrent data >> processing, maybe not parallel. >> >> On Mon Feb 09 2015 at 3:01:16 PM Marc Fawzi <[email protected]> wrote: >> >> Potentially naive question, but I thought I should get it out of the way :) >> >> Since in Javascript, there are no threads with shared memory, is there any >> performance advantage to using CLJS (vs JS, or Immutable.js vs mutable data >> structures) when it comes to parallel data processing? If so, are there any >> example specific to CLJS? >> >> Curious. >> >> >> >> >> -- >> Note that posts from new members are moderated - please be patient with your >> first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> >> -- >> Note that posts from new members are moderated - please be patient with your >> first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> >> > > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
