Thank you Jamie
It does seem to work in CLJS and have a very major effect
(defn vrange [n]
(loop [i 0 v []]
(if (< i n)
(recur (inc i) (conj v i))
v)))
(defn vrange2 [n]
(loop [i 0 v (transient [])]
(if (< i n)
(recur (inc i) (conj! v i))
(persistent! v))))
(time (def v (vrange 1000000)))
(time (def v2 (vrange2 1000000)))
"Elapsed time: 453 msecs"
"Elapsed time: 81 msecs"
It's very well reasoned as far as language features go, especially in a
tricky context like this
On Tue, Feb 10, 2015 at 2:21 PM, Marc Fawzi <marc.fa...@gmail.com> wrote:
> Wow,
>
> That *may be* super useful in places where "persistent data structures
> would allocate too many objects, especially in applications such as games
> that are sensitive to garbage collection" (googled around, and ingested)
>
> check this out
>
> http://theatticlight.net/posts/Conways-Game-of-Life-in-Clojurescript/
>
> IN LOVE <3
>
>
>
> On Tue, Feb 10, 2015 at 2:00 PM, Jamie Orchard-Hays <jamie...@gmail.com>
> wrote:
>
>> 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 <gary.trakh...@gmail.com>
>> 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 <marc.fa...@gmail.com>
>> 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 <marc.fa...@gmail.com> 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 <marc.fa...@gmail.com>
>>> 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 <gary.trakh...@gmail.com
>>>> > 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 <marc.fa...@gmail.com>
>>>>> 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 clojurescript+unsubscr...@googlegroups.com.
>>>>>> To post to this group, send email to clojurescript@googlegroups.com.
>>>>>> 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 clojurescript+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to clojurescript@googlegroups.com.
>>>>> 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 clojurescript+unsubscr...@googlegroups.com.
>>> To post to this group, send email to clojurescript@googlegroups.com.
>>> 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 clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescript@googlegroups.com.
>> 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 clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescript@googlegroups.com.
>> 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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
