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
25 matches
Mail list logo
