I've updated the library so tuples behave like vectors, rather than lists.
The macros have gotten kind of elephantine, but since I've already added
every conceivable Clojure interface at least they won't get any bigger. If
there are any lingering gaps, though, please let me know.
Zach
On
A Tuple protocol that defines get0 get1 get3 etc for fast element access
that doesn't tie you to using field names might be a good idea.
On 8/25/13 9:35 AM, Zach Tellman wrote:
I don't think so, even the existence of all the Tuple* types are an
implementation detail, and you'd need to hint it
I believe this is what clj-tuple is doing under the hood with macros.
On Aug 26, 2013, at 10:38 AM, Kevin Downey redc...@gmail.com wrote:
A Tuple protocol that defines get0 get1 get3 etc for fast element access
that doesn't tie you to using field names might be a good idea.
On 8/25/13 9:35
I had a quick look at clj-tuple and I don't remember seeing any macros...
Jim
On 26/08/13 19:02, Asim Jalis wrote:
I believe this is what clj-tuple is doing under the hood with macros.
On Aug 26, 2013, at 10:38 AM, Kevin Downey redc...@gmail.com wrote:
A Tuple protocol that defines get0
No, Asim is right, and the majority of LOC is macro code (which expands to
a deftype expression).
On Mon, Aug 26, 2013 at 11:51 AM, Jim - FooBar(); jimpil1...@gmail.comwrote:
I had a quick look at clj-tuple and I don't remember seeing any macros...
Jim
On 26/08/13 19:02, Asim Jalis
I'm not sure I understand the motivation behind what you're suggesting.
Why not just (nth tuple 0)?
On Mon, Aug 26, 2013 at 10:38 AM, Kevin Downey redc...@gmail.com wrote:
A Tuple protocol that defines get0 get1 get3 etc for fast element access
that doesn't tie you to using field names might
looking at clj-tuple a call to (nth some-tuple 0) turns in to a case
dispatch
(case idx
0 e0
...)
or something.
if you have a Tuple protocol with a function like get0 you can avoid the
overhead of the case there, and the jvm has a better change of inlining
the rest away.
for hotspot to
wow! very interesting stuff as always Zach...quick question:
I don't see Tuple implementing clojure.lang.Associative, so 'get' won't
work right?
Jim
ps: I've got a project where I 'm working with a lot of 2-element
vectors...I can't wait to try this out :)
On 25/08/13 03:38, Zach Tellman
I don't think so, even the existence of all the Tuple* types are an
implementation detail, and you'd need to hint it as the right one to get
sane performance. (nth t n) has good performance, you should prefer that.
On Saturday, August 24, 2013 8:15:40 PM UTC-7, Ben wrote:
Are the element
in my microbenchmarks I've found it to be consistently faster to unroll a
fixed number of elements rather than iterate over them. The difference
might not be large enough to matter for many people's use cases, but the
stated goal is to make a fast collection, so it's worthwhile to use the
Good stuff Zach - I've certainly wanted something like this on various
occasions.
Some comments:
- core.matrix will also work with clj-tuple (because they support ISeq)
- If you made the tuples support IPersistentVector I think they would be
even more useful: it's helpful I think to see tuples
I just pulled some code I wrote while trying to optimize 'memoize' into its
own library: https://github.com/ztellman/clj-tuple. It only has the one
function, so I assume no one will need too much explanation. However,
there may still be room for performance improvements, so if anyone wants to
Are the element names .e0, .e1 etc. considered part of the public interface
of tuple objects?
On Sat, Aug 24, 2013 at 7:38 PM, Zach Tellman ztell...@gmail.com wrote:
I just pulled some code I wrote while trying to optimize 'memoize' into
its own library: https://github.com/ztellman/clj-tuple.
Hi,
I've did something similar for CLJS, see
http://dev.clojure.org/jira/browse/CLJS-453 and
https://groups.google.com/forum/#!searchin/clojure/arrayvector/clojure/yDvTRP0gYLA/Tb5MJC8Z0K8J
In CLJS, it is comparable in performance to use array instead of
specialized type for each arity. Did you
14 matches
Mail list logo