Thanks for the elaboration, I just wanted to make sure I understood.
--
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
On Wednesday, 5 March 2014 08:19:26 UTC+8, Jarrod Swart wrote:
>
>
> On Monday, March 3, 2014 11:35:58 AM UTC-5, Mikera wrote:
>>
>>
>> Obviously, there are cases where allocating a sequence will be slower
>> than iterative techniques. But that's *easy enough to fix by just using
>> iterations
On Monday, March 3, 2014 11:35:58 AM UTC-5, Mikera wrote:
>
>
> Obviously, there are cases where allocating a sequence will be slower than
> iterative techniques. But that's *easy enough to fix by just using
> iterations in those cases* use the right tool for the job and all
> that.
>
>
I
I was not trying to generalize. I think that ISeq is not the right tool in
case where processing of large collection is a performance bottleneck. It
is perfectly OK for other purposes though.
Cons cell has its next object 'recorded', however this next object does not
have to be Cons, in which case
On 3/2/14, 7:06 PM, Mikera wrote:
Some perspectives (as someone who has been tuning this stuff a lot,
from a core.matrix standpoint in particular)
On Saturday, 1 March 2014 13:02:26 UTC+8, bob wrote:
Hi,
Can I ask a newbie question about clojure performance?
What make clojure per
On Monday, 3 March 2014 18:24:48 UTC+8, Jozef Wagner wrote:
>
>
> On Mon, Mar 3, 2014 at 3:06 AM, Mikera
> > wrote:
>
>> ISeq itself isn't too bad (it's just an interface, as above), but some of
>> the implementations are a bit expensive.
>>
>
> ISeq is inherently not suited for performance criti
On Mon, Mar 3, 2014 at 3:06 AM, Mikera wrote:
> ISeq itself isn't too bad (it's just an interface, as above), but some of
> the implementations are a bit expensive.
>
ISeq is inherently not suited for performance critical code, as next()
requires creation of a new object. Even if JVM handles suc
Cool, Kiss.
>From my 2 cent, the solid is important to the clojure, and the core team is
making any change carefully, but looks to me that the `radical` idea is
important to the community and clojure as well, might that we need a branch
of clojure to do some `radical` attempt and experiment, it
Some perspectives (as someone who has been tuning this stuff a lot, from a
core.matrix standpoint in particular)
On Saturday, 1 March 2014 13:02:26 UTC+8, bob wrote:
>
> Hi,
>
> Can I ask a newbie question about clojure performance?
>
> What make clojure performance slow than java?, it seems cloj
On Monday, 3 March 2014 02:18:39 UTC+5:30, tbc++ wrote:
>
> How are you running these tests? The "correct" way to benchmark such
> things is via a real benchmark framework (such as criterium) then compile
> your clojure app to a jar (perhaps via lein uberjar) and finally run it via
> a bare ja
How are you running these tests? The "correct" way to benchmark such things
is via a real benchmark framework (such as criterium) then compile your
clojure app to a jar (perhaps via lein uberjar) and finally run it via a
bare java invocation: java -jar my.jar.
Lein for example sometimes uses sub-p
I cannot agree with this...
Not at 100% at least.
String manipulations are frequent
enough to mandate some tuning
if the need is obvious.
Looks to me that this is the case here.
Other core fns went through rewrites
to improve performance.
Simplicity has nothing to do with
internal implementatio
On Sunday, 2 March 2014 12:49:15 UTC+5:30, Shantanu Kumar wrote:
>
>
>
> On Sunday, 2 March 2014 05:32:00 UTC+5:30, bob wrote:
>>
>>
>> Good point, Thanks a lot.
>>
>> Shall we improve the str fn in the core lib? From my point of view, the
>> core fns should be performance sensitive.
>>
>
> If
On Sunday, 2 March 2014 05:32:00 UTC+5:30, bob wrote:
>
>
> Good point, Thanks a lot.
>
> Shall we improve the str fn in the core lib? From my point of view, the
> core fns should be performance sensitive.
>
If string formation is the bottleneck in your app and if you can come up
with a versi
Core fns should be simple, unsurprising, and general.
'Improving' str may hurt simplicity, make behavior more surprising and
unexpected, and less general unless proven otherwise.
On Sat, Mar 1, 2014 at 7:02 PM, bob wrote:
>
> Good point, Thanks a lot.
>
> Shall we improve the str fn in the core
Good point, Thanks a lot.
Shall we improve the str fn in the core lib? From my point of view, the
core fns should be performance sensitive.
On Sunday, March 2, 2014 12:03:21 AM UTC+8, Shantanu Kumar wrote:
>
>
>
> On Saturday, 1 March 2014 15:32:41 UTC+5:30, bob wrote:
>>
>> Case :
>>
>> clo
On Saturday, 1 March 2014 15:32:41 UTC+5:30, bob wrote:
>
> Case :
>
> clojure verison:
>
> (time (dotimes [n 1000] (str n "another word"))) ;; take about 5000msec
>
> java version
>
> long time = System.nanoTime();
>
> for(int i=0 ; i<1000 ;i++){
> String a=i+
>From my experience, you can get 1/1.2 performance (20% slower) with Clojure
by following these steps:
* Choose right clojure idioms
That means to never use lazy seqs if you care for java-like performance.
For fast looping, use reducers, for fast inserts, use transients.
Postpone the data crea
Yep, you are right, inspecting the byte code generated by the clojure code:
(loop [n 0]
(when (< n 1000)
(-> (StringBuilder.) (.append n) (.append "another word")
(.toString))
(recur (unchecked-inc n
It is:
L4
LINENUMBER 4 L4
LLOAD 1
LDC 1000
Clojure math functions compile down to the same JVM 'instruction' as from
java. See http://galdolber.tumblr.com/post/77153377251/clojure-intrinsics
On Sat, Mar 1, 2014 at 1:23 PM, dennis zhuang wrote:
> I think the remaining overhead of clojure sample code is that operators in
> java such as '+
I think the remaining overhead of clojure sample code is that operators in
java such as '++' and '<" etc.They are just an instrument of JVM -- iinc
and if_icmpge. But they are both functions in clojure,and they will be
called by invokevirtual instrument.It cost much more performance.
2014-03-01
I forgot to note hat i test the java sample and clojure sample code with
the same jvm options '-server'.
2014-03-01 20:03 GMT+08:00 dennis zhuang :
> The "String a=i+"another word";" is also compiled into using
> StringBuilder, see the byte code by javap -v:
>
>Code:
> stack=5, local
The "String a=i+"another word";" is also compiled into using
StringBuilder, see the byte code by javap -v:
Code:
stack=5, locals=5, args_size=1
0: invokestatic #2 // Method
java/lang/System.nanoTime:()J
3: lstore_1
4: iconst_0
5: isto
Case :
clojure verison:
(time (dotimes [n 1000] (str n "another word"))) ;; take about 5000msec
java version
long time = System.nanoTime();
for(int i=0 ; i<1000 ;i++){
String a=i+"another word";
}
System.out.println(System.nanoTime()-time);
I have seen (and I keep seeing) a ton of Java code that performs poorly.
Empirically, it's equally easy to write a slow Java app. You always need a
discerning programmer to get good performance from any language/tool.
Numbers like 1/4 or 1/10 can be better discussed in presence of the
use-cases
Hi,
Can I ask a newbie question about clojure performance?
What make clojure performance slow than java?, it seems clojure has the 1/4
performance compared to java in general, according to tests, some cases it
might be 1/10. the reasons I can think out are
- the byte code is not efficient so
JVM is very slow to start. Try measuring around your method calls instead.
Also try running it for a long enough time to see the JVM GC kick the butt
of python's GC...
On Fri, Jul 8, 2011 at 6:19 PM, Michael Klishin wrote:
> 2011/7/9 Christopher
>
>> % time cake run mapper.clj < input.txt
>>
Hi David,
Thanks for the comments and the code rewrite. This is excellent
information. I just tried it out on my own system and got the same
results. This is a really great example of how to optimize Clojure
code. I'm considering using Clojure for some more research-oriented
work where I will need
Thanks Benny. I tried again without using cake and just compiling the
code into a jar and it does execute much better. I guess using the
cake run command as a way to avoid the JVM startup overhead isn't the
best option for writing highly performant code. I was kind of hoping
that after the first ru
Here's a very ugly low-level version just to show that it can be done:
(ns clj-play.mapper
(:use [clojure.java.io :only [reader]])
(:use [clojure.string :only [split]])
(:gen-class))
(set! *warn-on-reflection* true)
(defn mapper [^java.io.BufferedReader r ^java.io.OutputStreamWriter out]
Running a program like that with cake run is awful, use AOT:
(ns clj-play.mapper
(:use [clojure.java.io :only [reader]])
(:use [clojure.string :only [split]])
(:gen-class))
(defn mapper [lines]
(doseq [line lines]
(doseq [word (split line #"\s+")]
(println (str word "\t1"))
Hi Christopher,
I ran your code with only one modification, using the "time" macro to
measure the execution time of the mapper function itself:
(use ['clojure.java.io :only '(reader)])
(use ['clojure.string :only '(split)])
(defn mapper [lines]
(doseq [line lines]
(doseq [word (split line
Hi Ken,
Thanks for the comment. I tried what you suggested, but I am not
getting any reflection warnings. That said, comments like this are
exactly what I am looking for; I had no idea that you could turn on
checking for reflection issues. I'd love it if I could find a way to
speed this piece of c
On Jul 8, 4:17 pm, Ken Wesson wrote:
> On Fri, Jul 8, 2011 at 7:05 PM, Christopher wrote:
> > ;; mapper.clj
>
> > (use ['clojure.java.io :only '(reader)])
> > (use ['clojure.string :only '(split)])
>
> > (defn mapper [lines]
> > (doseq [line lines]
> > (doseq [word (split line #"\s+")]
> >
Hi Michael,
Thanks for the comments, though, I want to point out that I'm using
cake to run the program which keeps an instance of the JVM spun up at
all times. That should remove the startup time, unless I am
misunderstanding how cake works. Also, the startup time should be
constant (say a few se
2011/7/9 Christopher
> % time cake run mapper.clj < input.txt
> real0m3.573s
> user0m2.031s
> sys 0m1.528s
>
These numbers include JVM startup overhead (which is significant compared to
Python startup overhead).
--
MK
http://github.com/michaelklishin
http://twitter.com/michaelklis
On Fri, Jul 8, 2011 at 7:05 PM, Christopher wrote:
> ;; mapper.clj
>
> (use ['clojure.java.io :only '(reader)])
> (use ['clojure.string :only '(split)])
>
> (defn mapper [lines]
> (doseq [line lines]
> (doseq [word (split line #"\s+")]
> (println (str word "\t1")
>
> (mapper (line-seq
Hi all,
I have recently been watching a set of videos from O'Reilly on
MapReduce. The author of the series is using Python for all of the
examples, but, in an effort to use Clojure more, I've been following
along and writing my code in Clojure. When I implemented the mapper
function that he descri
38 matches
Mail list logo
