Hi Mark F,
Thanks for your responses.
> 1. Data: Is this really a problem that is slowing down Clojure
> programs in practice? Can you provide some data to that effect? I
> would suggest writing a couple of Java benchmarks - one that updates a
> simple structure in place and one that only creates new data. Time
> them. Write more benchmarks, but this time do it in Clojure (though
> perhaps with some straight Java calls to make the updates). Are there
> differences in the Java versions from the Clojure versions? Are there
> differences in the update vs new data versions?
Writing some test code is not a bad idea, but from what I
heard Rich Hickey say in his online talks, probably unnecessary
to establish that using Clojure built-in data structures
involves a performance hit (in the single-thread case anyway).
I got the impression that Clojure structures are somewhere
in the range of 1.5 to 4 times worse than mutation based
structures. Of course, this performance is quite an achievement,
given the advantages of Clojure's approach. But for applications
which are performance critical, I am wondering whether
a uniqueness-based update-in-place would offer a
complementary well performing alternative.
> 2. Take a page from the Scheme playbook. Don't ask the language to
> implement this feature, ask for the minimal set of tools that you need
> to implement it. I would think a code walking escape analysis macro
> could be very useful. Instead of run-time reference counting, the
> macro could find data that is guaranteed not to escape its scope via a
> closure (e.g. let bound locals that are not used in any (fn
> [] ...)s ). What would you need access to? Additional JVM byte-code
> instructions? Post-compile processing by user code? Update in place
> methods for the normally immutable types? I don't know exactly what
> you'd need, but ask for that before asking for a much bigger feature.
The escape analysis macro sounds interesting. But an initial approach
might be, for each of these new data structures (mutation based under
the hood) to have two versions of each structure:
* immutable (ie no more changes will ever occur - if you want a
modification you will have to make a full copy); and
* uniquely-referenced (arbitrary mutation changes effectively
allowed, but only ever referred to uniquely (runtime enforced)).
Most structures of this type would start life as a uniquely-referenced
structure (either empty or a copy of an immutable), and have
lots of mutations effectively applied to them in a safe environment,
until they are ready to be "frozen" and released to the world as
an immutable version of the structure. (Some structures would
stay uniquely-referenced their whole life - used for performance
in some single-threaded encapsulated mutation-based algorithm.)
I should also clarify one point. I am not "asking for this language
feature" so much as "asking whether people have thought
about it". There may (or may not) be good reasons for not offering
such a language feature. I'm just wondering if it has been
considered. (And trying to get a feel for the strengths and
weaknesses of Clojure - I am very new to it.)
> 3. Remember that Clojure relies on the JVM for its allocation and GC.
> Clojure is not issuing malloc and free calls. The JVM will not make it
> easy to repurpose the storage of one object with a new object, without
> going through a method.
Maybe the way to handle this (at least initially) would be to only
provide
uniqueness interfaces to some of Java's main structures. Perhaps not
as general as would be ideal, but would easily allow repurposing via
a
method.
Thanks again for your input.
Cheers,
Mark P.
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
