gen-class is only right when you need to do concrete inheritance. That may be
true when doing Java interop, but with a well-designed Java library it doesn't
have to be.
Stu
> Thanks for that benchmark example, Rich. One thing that really
> intrigues me here is that the reify version is substa
Thanks for that benchmark example, Rich. One thing that really
intrigues me here is that the reify version is substantially faster
than the gen-class version. Is there any way to harness the speed of
the reify from external Java libraries calling into Clojure, or is
gen-class still pretty much th
On Dec 28, 2010, at 8:57 PM, Mark Engelberg wrote:
Just for fun, I was curious to see what it would be like,
performance-wise, to simulate a synchronized mutable hash map by
putting a clojure hash map inside an atom, and making this accessible
to Java code via the map interface.
I didn't try t
On Wed, Dec 29, 2010 at 1:28 AM, Mark Engelberg wrote:
> It just means I have to rethink my proselytizing strategy -- I was
> definitely overselling the speed of the persistent data structures.
>
I agree, trying to sell persistent data structures on speed alone just
doesn't make sense. Any talk
On Dec 29, 2010, at 1:28 AM, Mark Engelberg wrote:
> On Tue, Dec 28, 2010 at 10:15 PM, David Nolen wrote:
>> Even in in a single threaded context raw insert performance isn't the final
>> word. What if you want to be able to deliver a snapshot for reporting?
>
> What if you don't?
>
> Seriousl
On Tue, 28 Dec 2010 22:28:54 -0800
Mark Engelberg wrote:
[Standing on soapbox]
> On Tue, Dec 28, 2010 at 10:15 PM, David Nolen wrote:
> > Even in in a single threaded context raw insert performance isn't the final
> > word. What if you want to be able to deliver a snapshot for reporting?
>
> W
On Wed, Dec 29, 2010 at 5:13 AM, nicolas.o...@gmail.com
wrote:
> I never was fully convinced an atom around a functional hash was
> perfect for concurrency.
>
> There is no write/write or read/write concurrency possible, even on
> independent data.
There is if you resort to (mutable)
java.util.co
On Wed, Dec 29, 2010 at 1:08 AM, Todd wrote:
> I thought it'd be interesting to look closer at the insertion times as a fx
> of the size of the Map. The results are at:
>
> https://gist.github.com/758198
>
> At first I thought I'd found something interesting, only to investigate
> further and real
I never was fully convinced an atom around a functional hash was
perfect for concurrency.
There is no write/write or read/write concurrency possible, even on
independent data.
Someone was working a while ago ob TransactionalHashMap, if I recall well.
Is there something already to benchmark agains
Hi Mark,
I understand the value of, sometimes, comparing raw speed of simple
datastructures operations.
So in your example, if I understand correctly, you're not computing the time
taken to compute the new value to be inserted, but rather just the time of
insertion.
I've seen in the past collegue
> Since transients enforce single-threadedness, there's no reason to put
> it in an atom. You're right that would work for the truly
> single-threaded scenario. I'm more interested right now in the
> scenario of "multi-threaded, low-contention, only occasionally need a
> snapshot (for iteration w
On Tue, Dec 28, 2010 at 11:16 PM, Jason Wolfe wrote:
> Use transients?
>
> (dotimes [_ 10]
> (let [m (atom (transient {}))
> r (range 1e5)]
> (time
> (doseq [i r]
> (swap! m assoc! i 2)
Since transients enforce single-threadedness, there's no reason to put
it in an atom. Yo
On Dec 28, 10:28 pm, Mark Engelberg wrote:
> On Tue, Dec 28, 2010 at 10:15 PM, David Nolen wrote:
> > Even in in a single threaded context raw insert performance isn't the final
> > word. What if you want to be able to deliver a snapshot for reporting?
>
> What if you don't?
Use transients?
(
On Tue, Dec 28, 2010 at 10:15 PM, David Nolen wrote:
> Even in in a single threaded context raw insert performance isn't the final
> word. What if you want to be able to deliver a snapshot for reporting?
What if you don't?
Seriously, I agree with you that Clojure's data structures have some
sign
On Wed, Dec 29, 2010 at 12:27 AM, Mark Engelberg
wrote:
> Clearly, I couldn't really answer that question without doing some
> investigating to see what the speed difference is like. I was even
> hoping that if the speed difference were small enough, I could bundle
> up a little library that impl
I thought it'd be interesting to look closer at the insertion times as a
fx of the size of the Map. The results are at:
https://gist.github.com/758198
At first I thought I'd found something interesting, only to investigate
further and realize that I'd been testing through a fx that was using
On Tue, Dec 28, 2010 at 6:46 PM, David Nolen wrote:
> So it's about 5X-6X slower for 1e5. But it looks to me there's no overhead
> from atom operations.
I got similar results (5x slower) on the same sorts of tests. Calling
it from the class generated by genclass seemed to cause another 2x
slowdo
On Tue, Dec 28, 2010 at 8:57 PM, Mark Engelberg wrote:
> Just for fun, I was curious to see what it would be like,
> performance-wise, to simulate a synchronized mutable hash map by
> putting a clojure hash map inside an atom, and making this accessible
> to Java code via the map interface.
>
;;
Just for fun, I was curious to see what it would be like,
performance-wise, to simulate a synchronized mutable hash map by
putting a clojure hash map inside an atom, and making this accessible
to Java code via the map interface.
I didn't try to implement the entire map interface, but just the majo
19 matches
Mail list logo
