trying to
get an algorithm in Clojure to match Java speed and managed to get the
performance to within one order of magnitude and wondering if more is
possible. The full question is here:
http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
Thank you
On Wednesday, February 27, 2013 2:46:25 PM UTC-8, Ben Mabey wrote:
On 2/27/13 9:59 AM, Isaac Gouy wrote:
(defn blank? [s] (every? #(Character/isWhitespace %) s))
Have you ever wondered about its performance?
No. Why would I wonder about the performance of a one line code snippet
It's in the official API
documentationhttp://clojure.github.com/clojure/branch-master/clojure.core-api.html#clojure.core/reduced.
Yes, it's new with Clojure 1.5.
On Friday, March 1, 2013 12:42:18 AM UTC+1, Geo wrote:
I didn't know reduce could be short circuited! I assume from the code
I didn't know reduce could be short circuited! I assume from the code below
this is done calling the function reduced? Is this in Clojure 1.5 only and
is where is this documented?
On Wednesday, February 27, 2013 4:59:33 AM UTC-5, Christophe Grand wrote:
On Wed, Feb 27, 2013 at 10:21 AM,
On Wednesday, February 27, 2013 12:53:14 AM UTC+1, Luc wrote:
Why insist on getting Clojure to be at par with languages that may offer a
performance
boost on narrow problems at the expense of making parallel processing and
code
in general more complex everywhere else ?
This doesn't
On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote:
If idiomatic Clojure was used...
The problem, of course, is that: the code one-person considers to be
idiomatic; another person considers to be idiotic, naïve.
Not really. Take Stuart Halloway's opening example in the
(defn blank? [s] (every? #(Character/isWhitespace %) s))
Have you ever wondered about its performance? Here you go:
user (time (dotimes [_ 1] (blank?
)))
Elapsed time: 3887.578 msecs
To give a more complete picture, this version
(defn
On Wed, Feb 27, 2013 at 10:21 AM, Marko Topolnik
marko.topol...@gmail.comwrote:
(defn blank? [s] (every? #(Character/isWhitespace %) s))
Have you ever wondered about its performance? Here you go:
user (time (dotimes [_ 1] (blank?
)))
Elapsed time: 3887.578 msecs
To
On Wednesday, February 27, 2013 10:59:33 AM UTC+1, Christophe Grand wrote:
Now that reduce can be short-circuited, redifining every?, some and al on
top of it would yield some interesting gains:
(defn revery? [pred coll]
(reduce (fn [t x]
(if (pred x)
t
Hi,
the recur is not for optimisation but for short-circuiting so that every?
kind of works like and. Stoppable reduce allows now to exploit the internal
reduce for strings while still keeping the short-circuiting of every?.
Kind regards
Meikel
--
--
You received this message because you
On Wed, Feb 27, 2013 at 11:20 AM, Marko Topolnik
marko.topol...@gmail.comwrote:
On Wednesday, February 27, 2013 10:59:33 AM UTC+1, Christophe Grand wrote:
Now that reduce can be short-circuited, redifining every?, some and al on
top of it would yield some interesting gains:
(defn revery?
Well then lets stop trying to twist the code further. Commenting that Clojure
looses
in these benchmarks or is pushed in the same backyard than ruby is counter
productive.
What I have seen so far is pulling toward extreme contorsions to achieve
better performance at the expense of code
In your specific case, where you want every last inch of performance, it is
acceptable that you will need to use the optimized idiom. However, if your
overall code did anything else besides banging hard against your algorithm,
a performance say 5 times worse than Java may soon become
On Wednesday, February 27, 2013 12:48:13 AM UTC+1, David Nolen wrote:
Hang out with JRuby? Seriously?
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=alllang=clojurelang2=jruby
Well, all the code-size bars are above the baseline :) Let's see how it
fares when they disappear
I disagree with your last statement. If you look backward, you will find that
most
languages were created with one or two strong influential ideas at the start.
Many of them died of not being extendable to meet new concepts
(Snobol, Algol, Simula, APL, ...)
It did not prevent many of them to
On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote:
On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote:
If idiomatic Clojure was used...
The problem, of course, is that: the code one-person considers to be
idiomatic; another person considers to be
On Wednesday, February 27, 2013 5:17:16 PM UTC+1, Luc wrote:
There's no magic. You cannot win on all fronts.
You defeatist, you :) I'm just trying to represent the enthusiastic
perspective where if it *could* be better, it *must* be better. In many
respects Clojure already embodies exactly
On Wednesday, February 27, 2013 5:59:25 PM UTC+1, Isaac Gouy wrote:
(defn blank? [s] (every? #(Character/isWhitespace %) s))
Have you ever wondered about its performance?
No. Why would I wonder about the performance of a one line code snippet
that was written without concern for
Luc makes a good point. And that's one thing that I love about Clojure. It
is possible to have (more or less) the same language on different platforms
with different trade-offs, with little effort. Just look at the three
examples we have now:
Clojure - Pretty awesome performance + interop with
And by with little effort I mean with little effort compared to porting
other languages to different platforms.
Given 8 hour work days a single man can hack out Clojure on almost any
platform in a few months. That's quite impressive considering how hard it
would be to do the same for
On Feb 27, 2013, at 9:07 AM, Marko Topolnik wrote:
On Wednesday, February 27, 2013 5:59:25 PM UTC+1, Isaac Gouy wrote:
(defn blank? [s] (every? #(Character/isWhitespace %) s))
Have you ever wondered about its performance?
No. Why would I wonder about the performance of a one line
On Wednesday, February 27, 2013 6:28:03 PM UTC+1, Andy Fingerhut wrote:
If you wanted to create a collection of idiomatic Clojure programs for
solving a particular set of problems, e.g. the Benchmarks Game problems, as
soon as more than one person submitted a program and/or reviewed a
On Wednesday, February 27, 2013 9:48:15 AM UTC-8, Marko Topolnik wrote:
However, if someone comes along with *(let [m (HashMap.)] (loop
[]...(recur (.put m ...)))* claiming that is in fact idomatic, he's just
being unreasonable---by everyone's agreement.
You don't think there are
On 2/27/13 9:59 AM, Isaac Gouy wrote:
On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote:
On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote:
If idiomatic Clojure was used...
The problem, of course, is that: the code one-person
I beg to differ. You can't separate an assessment of idiomaticity
from the specific problem domain. *That* is true no matter what the
language.
On Feb 27, 9:48 am, Marko Topolnik marko.topol...@gmail.com wrote:
On Wednesday, February 27, 2013 6:28:03 PM UTC+1, Andy Fingerhut wrote:
If you
This is a great analysis, thanks for the link; shame it's so old.
On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote:
Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely
tuned submissions. That would allow you to get some sort of an idea how
performant
As Issac pointed out, here are some very recent graphs (including Clojure):
http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
On 2/26/13 2:35 AM, Marko Topolnik wrote:
This is a great analysis, thanks for the link; shame it's so old.
On Sunday, February 24, 2013
I see; didn't notice that one. Again, only the fastest entries are shown.
It appears that the same is the case with Marceau's graphs; he just didn't
state that explicitly.
Things don't look very rosy for Clojure: it turns out to be about as
verbose as Java and significantly slower (this
I've got a github repo with submissions for the Benchmarks Game web site for
Java and Clojure, with several different Clojure programs for most problems:
https://github.com/jafingerhut/clojure-benchmarks
If people would like to submit what they consider idiomatic Clojure programs
for any
Clojure code should in principle be possible to execute very fast when
using the same data structures. Clojure is much better behaved than
languages like Ruby and Javascript from a compiler perspective. See for
example the Stalin scheme compiler. It runs well written Scheme at almost C
speed
On Tue, Feb 26, 2013 at 3:50 PM, Marko Topolnik marko.topol...@gmail.comwrote:
Things don't look very rosy for Clojure: it turns out to be about as
verbose as Java and significantly slower (this confirms my experience;
slightly slower than *regular* Java code, significantly slower than
highly
I you attempt to mimic Java or C in some narrow linear
compute bound algorithm, I agree that the resulting code is quite ugly, not
idiomatic
on top of having performance issues.
Lucky for us not all the problems are bounded like this.
I have been following this thread from the beginning and I
On Tuesday, February 26, 2013 12:50:17 PM UTC-8, Marko Topolnik wrote:
Again, only the fastest entries are shown.
True, except for the special-case included to show that programs can be
made slower (and sometimes more concise) -- the shortest C++ programs.
If idiomatic Clojure was
This is pretty neat. Thanks!
Yeah the swapping of prev and curr seems to be a stumbling block.
On Sunday, February 24, 2013 6:08:39 PM UTC-5, Aria Haghighi wrote:
I have a solution (gist here https://gist.github.com/aria42/5026109, key
bits pasted below). It's pretty short (15 lines) and
Hi,
Nice solution, but don't we need to distinguish between the array types ?
(cf. inline comment below )
Cheers,
B.
On Monday, February 25, 2013 12:08:39 AM UTC+1, Aria Haghighi wrote:
[…] Here, I think it's a macro you'll probably use all over the place,
arr-max, which will find the
On Thursday, February 21, 2013 10:27:11 PM UTC+1, Geo wrote:
Man, this is exactly how I feel after all this tinkering! It was great for
learning Clojure a bit more in depth, but in the end I am going to stick
with the Java solution. Especially since it's so easy to mix Java and
Clojure
Well I'll just say that my opinion on this matter is not well formed at the
moment since this is the first time I have encountered this issue. For now
I've stuck with the Java algorithm so I can move on with my project, but I
do plan to revisit this at some point. In fact, it may be important
On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote:
FWIW, I, for one, am really glad that Clojure allows us to select
precisely which nice tools we want (have to) throw away (persistent data
structures, dynamic typing, synchronized) when the need arises. Reminds me
of the don't
On Sunday, February 24, 2013 4:27:34 PM UTC+1, Geo wrote:
At the moment I don't find the Clojure solution simple, but again this may
simply be to lack of exposure. Have you written a lot of performance
optimized Clojure?
Yes, that's the catch, isn't it? If we had to write Clojure in the
On Feb 24, 2013, at 10:46 , Marko Topolnik marko.topol...@gmail.com wrote:
from what I hear, idiomatic Haskell is a performance devil as well
Does this mean very good, or very bad?
On a related note, is there currently any way to get the Clojure compiler to
tell you where boxing is occurring,
On Feb 24, 2013, at 8:46 AM, Marko Topolnik wrote:
On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote:
FWIW, I, for one, am really glad that Clojure allows us to select precisely
which nice tools we want (have to) throw away (persistent data structures,
dynamic typing,
Take a look at any of the Common Lisp or Haskell submissions to the
Computer Language Benchmarks Game web site, and you will see some programs
that are nowhere near what people typically write in those languages, and
certainly not what people would write if they weren't concerned with
from what I hear, idiomatic Haskell is a performance devil as well
Does this mean very good, or very bad?
It means the same as in speed devil :)
On a related note, is there currently any way to get the Clojure compiler
to tell you where boxing is occurring, like
On Feb 24, 2013, at 9:33 AM, Marko Topolnik wrote:
Take a look at any of the Common Lisp or Haskell submissions to the Computer
Language Benchmarks Game web site, and you will see some programs that are
nowhere near what people typically write in those languages, and certainly
not what
On Sun, Feb 24, 2013 at 5:50 AM, bernardH
un.compte.pour.tes...@gmail.comwrote:
FWIW, I, for one, am really glad that Clojure allows us to select
precisely which nice tools we want (have to) throw away (persistent data
structures, dynamic typing, synchronized) when the need arises. Reminds me
I'm no Haskell expert, but it doesn't take much Googling to give strong
evidence that the answer is yes, you can get mutability in Haskell.
Search through this Haskell program on the Benchmarks Game site for
occurrences of the string unsafe.
I see; quite disgusting :)
In my
On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote:
As I mentioned before, I'm generally happy with Clojure's performance, but
the few times I've had performance problems, I ended up rewriting the code
at least three different ways in order to try to find the magic combination
On Sunday, February 24, 2013 9:45:18 PM UTC+1, Marko Topolnik wrote:
On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote:
As I mentioned before, I'm generally happy with Clojure's performance,
but the few times I've had performance problems, I ended up rewriting the
code at
On 2/24/13 1:34 PM, Marko Topolnik wrote:
I'm no Haskell expert, but it doesn't take much Googling to give
strong evidence that the answer is yes, you can get mutability in
Haskell. Search through this Haskell program on the Benchmarks
Game site for occurrences of the string
I have a solution (gist here https://gist.github.com/aria42/5026109, key
bits pasted below). It's pretty short (15 lines) and readable (I think) and
only 50% slower than the Java version on my machine (averaging over 25 runs
of your benchmark function).
Generally, I've found it's really easy
On Sunday, February 24, 2013 9:33:52 AM UTC-8, Marko Topolnik wrote:
For example, Scala beats Java by a wide margin on some benchmarks. Turns
out it's because it uses JNI to solve the problem with the C bignum
library.
Turns out the benchmarks game website shows both Scala programs
On Sunday, February 24, 2013 1:45:33 PM UTC-8, Ben Mabey wrote:
Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely
tuned submissions.
So you wish the benchmarks game website would show, for example, both
pi-digits programs that use BigInteger and pi-digits programs
On Fri, Feb 22, 2013 at 7:47 PM, Korny Sietsma ko...@sietsma.com wrote:
Isn't that always the way, though? Build your program in a powerful,
expressive language, then profile it, find the critical parts, and optimise
them - where possible in the same language, and where that's too
I tend to think clojure is in a similar position - fast enough for the
vast majority of things (ymmv of course - depending on what your domain is)
and if you meet a situation like this where optimising the clojure becomes
too ugly, you can drop down to Java (or indeed C!)
Not quite, I'd
From my (admittedly limited) experience with Scala, yes, you can freely use
reassignable local vars and write pretty much the same loops as in Java,
but on the other hand there are many non-obvious performance pitfalls (like
simply using the built-in *for comprehension*) and the optimized
Lisp programmers know the value of everything and the cost of nothing ;)
On Saturday, February 23, 2013, Marko Topolnik wrote:
I tend to think clojure is in a similar position - fast enough for the
vast majority of things (ymmv of course - depending on what your domain is)
and if you meet a
:)
On the other hand, the Common Lisp movement of the '80s was brimming with
the can-do attitude of achieving native performance. From Steele, Gabriel, *The
Evolution of Lisp*:
the two strongest voices—Steele and Gabriel—were feeling their oats over
their ability to write a powerful compiler
Stack analysis is quite a brittle mechanism, as far as I'm aware of. As
soon as you pass the object to any method, even if private, the object will
not be stack-allocated. The way Clojure code is typically written, and the
way it is compiled, some method call will almost certainly get involved.
Just wanted to say I am getting a lot out of this discussion.
--
--
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
Note that posts from new members are moderated - please be patient with your
and wondering if more is
possible. The full question is here:
http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
Thank you.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email
Java speed and managed to get the
performance to within one order of magnitude and wondering if more is
possible. The full question is here:
http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
Thank you.
On Monday, February 18, 2013 11:16:51 PM UTC-5
On Thursday, February 21, 2013 10:49:42 PM UTC+1, David Nolen wrote:
On Thu, Feb 21, 2013 at 4:55 AM, Marko Topolnik
marko.t...@gmail.comjavascript:
wrote:
Whatever the final performance achieved, the fact remains that the
original Java code was much cleaner, simpler, and more
Marko Topolnik marko.topol...@gmail.com writes:
Christophe's version also has the advantage that it can pretty much
compile down to efficient JavaScript via ClojureScript and probably an
efficient ClojureCLR program as well. This may or may not matter to you.
Apparently even Cristophe broke
Perhaps it's time to hit the decompiler :) AOT compile and apply javap; do
the same for a comparable Java version. This will be a time-consuming and
frustrating experience and it won't bring you lasting insight into
performant Clojure because things will change around in the next release.
On
I'd look at it the other way around. It would be good if someone did
this, so that it would change around in the next release, and I won't
have to have any lasting insight into the performant Clojure.
I wasn't the OP, BTW, although I suspect he and I share a profession.
String matching
That would exactly be my point, too: I want to write idiomatic Clojure and
have the underlying runtime make it perform; that's what I get with Java. I
don't want to twist the compiler's arm into producing the bytecode that I
can get from straightforward Java code.
Incidentally, it happens that
On Fri, Feb 22, 2013 at 3:43 AM, Marko Topolnik marko.topol...@gmail.comwrote:
My 5-year experience with Clojure (since 0.9) hasn't helped me to see it
that way.
I've been doing Clojure for about 5 years as well. Optimizing Clojure in
the early days was pretty tough stuff, and resorting to
It's right there in the docstring of deftype, but OK.
...followed by several sentences of big fat warnings, including that they
are present only to facilitate the building of higher
level constructs, such as Clojure's reference types, in Clojure
itself.
Other than that, you are right,
On Fri, Feb 22, 2013 at 2:06 PM, Marko Topolnik marko.topol...@gmail.comwrote:
Fair enough. My point was simply that Clojure implementations have a small
learnable subset that performs well when performance is desired -
primitives, loops, arrays, deftypes, etc regardless of host. It's
Er re: assigning stack based locals. Forget wasting time making a tuple
type, probably best to just do that with a small mutable array. This worked
ok for us when porting some Java persistent data structure code to
ClojureScript.
On Friday, February 22, 2013, David Nolen wrote:
On Fri, Feb 22,
On Friday, February 22, 2013 8:23:38 PM UTC+1, David Nolen wrote:
I'll give you one specific item that I keep tripping upon: the lack of
reassignable, stack-based locals. Without them I can't efficiently get more
than one value out of a loop. Another item is that I can get zero
On Friday, February 22, 2013 8:44:30 PM UTC+1, Marko Topolnik wrote:
* implement efficient tuple type which uses mutation for multiple value
return
Basically, this is the ^:unsynchronized-mutable that we just mentioned :)
This is much better, but still it's not stack-based, so
On Friday, February 22, 2013, Marko Topolnik wrote:
Annoying *and* slower than Java's locals, unfortunately. Most of the time
it won't make a huge dent in the performance, but I just happen to have an
inner loop that iterates between zero and three times only, zero being by
far the most
On Friday, February 22, 2013 9:04:31 PM UTC+1, David Nolen wrote:
On Friday, February 22, 2013, Marko Topolnik wrote:
Annoying *and* slower than Java's locals, unfortunately. Most of the
time it won't make a huge dent in the performance, but I just happen to
have an inner loop that
On Friday, February 22, 2013 8:41:15 PM UTC+1, David Nolen wrote:
Er re: assigning stack based locals. Forget wasting time making a tuple
type, probably best to just do that with a small mutable array. This
worked ok for us when porting some Java persistent data structure code to
OK, though threading one 3 element object array into the loop with one
double cast doesn't really seem that problematic or slow to me.
On Fri, Feb 22, 2013 at 3:27 PM, Marko Topolnik marko.topol...@gmail.comwrote:
On Friday, February 22, 2013 8:41:15 PM UTC+1, David Nolen wrote:
Er re:
Oh right, sorry, you don't want to pay for boxing the double. Yeah this is
the case where you'd want to go with a tuple. If this really was common in
my own code I would probably write a mutable tuple macro. But I totally
understand why someone else might just write the Java if they just want
It wouldn't be a first for me, either; I'm already accustomed to writing
macros for performance. For example, unrolling writer.append loops, using
jassoc as a Java HashMap replacement for assoc, and many similar tricks.
On this particular occasion, where the performance-critical code segment
Isn't that always the way, though? Build your program in a powerful,
expressive language, then profile it, find the critical parts, and optimise
them - where possible in the same language, and where that's too
ugly/painful, drop down a layer to a lower level language.
I did lots of this in the
I updated my answer on SO, with a deftype-based one that gives me an
additional 30% boost.
On Tue, Feb 19, 2013 at 6:38 PM, Geo ggrigor...@gmail.com wrote:
What about the call to .equals?
On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote:
The difference between
Ah, yes, thought it was wrong somewhere!
Stephen Compall stephen.comp...@gmail.com writes:
On Feb 20, 2013 5:55 AM, Phillip Lord phillip.l...@newcastle.ac.uk
wrote:
(do
(assoc curr (inc j) 0)
(recur (inc j) max-len)))
Man, this is exactly how I feel after all this tinkering! It was great for
learning Clojure a bit more in depth, but in the end I am going to stick
with the Java solution. Especially since it's so easy to mix Java and
Clojure in the same project! I just specify :java-source-paths [src/java]
in
This thread made me realize there's quite a bit of low hanging
compatibility fruit between Clojure ClojureScript, so as of this
changeset
http://github.com/clojure/clojurescript/compare/4652498035...3c0fb6ef5f
We can now compile Christophe's example code in ClojureScript w/ exactly 4
minor
:
http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
So, I was curious about this. So, you've done everything using java
arrays. What would happen if you used clojure data structures.
So I tried this instead.
(defn lcs-native
[n1 n2]
(let [n1-len (count n1
On Feb 20, 2013 5:55 AM, Phillip Lord phillip.l...@newcastle.ac.uk
wrote:
(do
(assoc curr (inc j) 0)
(recur (inc j) max-len)))
Here you're discarding the result of assoc, a pure function, which changes
the code's nature
Another idea: try using arrays of longs, rather than ints, since that is
what Clojure prefers.
--
--
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
Note that posts from new members are
-performance-for-expensive-algorithms
Thank you.
--
--
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
Note that posts from new members are moderated - please be patient with your
first
Using long-array instead of int-array seems to produce a very slight but
noticeable improvement. (~2.1 sec - ~1.8 sec) = 1.16x improvement
One other thing is that loop seems to return boxed primitives, so by
wrapping the inner loop with (long ) I got another slight performance gain.
(~2.5 sec
One thing I don't get is that switching the type hints from
[#^[Ljava.lang.String; a1 #^[Ljava.lang.String; a2]
to [^objects a1 ^objects a2] didn't seem to have any negative impact on
performance. Can anyone explain why hinting ^objects is just as good as
specifying that it's an array of
^objects is a Clojure synonym for ^[Ljava.lang.Object;. Note that there are
such synonyms for only a few Java types, not everything, e.g. there is no
^strings.
What you are hinting is that a1 and a2 are Java arrays of objects. I think
this might speed up (aget a1 i) expressions, since it is
Note that I'm not very confident that using long-array instead of int-array
is a true improvement vs. just noise.
On Tuesday, February 19, 2013 11:46:21 AM UTC-5, Geo wrote:
Using long-array instead of int-array seems to produce a very slight but
noticeable improvement. (~2.1 sec - ~1.8 sec)
The difference between String[] and Object[] is that a member of the former
doesn't need a checked cast to String, but the latter does need one. In the
code under consideration, however, nothing specific to String is used, so
even in the Java code you can freely replace String[] with Object[]
What about the call to .equals?
On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote:
The difference between String[] and Object[] is that a member of the
former doesn't need a checked cast to String, but the latter does need one.
In the code under consideration, however,
Naturally, it's Object#equals. String's override of equals gets involved
without the checked downcast.
On Tuesday, February 19, 2013 6:38:07 PM UTC+1, Geo wrote:
What about the call to .equals?
On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote:
The difference between
Cool. Thanks for the explanation.
On Tuesday, February 19, 2013 12:47:05 PM UTC-5, Marko Topolnik wrote:
Naturally, it's Object#equals. String's override of equals gets involved
without the checked downcast.
On Tuesday, February 19, 2013 6:38:07 PM UTC+1, Geo wrote:
What about the call to
/questions/14949705/clojure-performance-for-expensive-algorithms
Thank you.
--
--
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
Note that posts from new members are moderated - please be patient
to match Java speed and managed to get the
performance to within one order of magnitude and wondering if more is
possible. The full question is here:
http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
Thank you.
--
--
You received this message
97 matches
Mail list logo
