Clojure count and get functions much faster on strings than direct interop with .length and .charAt

I am writing an expensive algorithms in Clojure and while trying to optimize the code I discovered something that puzzled me. Clojure count and get functions are much faster on strings than direct interop with .length and .charAt. On my machine I get the following: (def sss (apply str (repeat 1

Re: Clojure count and get functions much faster on strings than direct interop with .length and .charAt

Thank you! Adding type hints solves the problem. The interop now slightly outperforms Clojure's get and count. So how come Clojure's get and count don't incur the reflection penalty? On Sunday, February 17, 2013 9:17:55 AM UTC-5, Geo wrote: > > I am writing an expensive

Re: Clojure count and get functions much faster on strings than direct interop with .length and .charAt

Clojure is full of pleasant surprises :) > > -- -- 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 post. T

Clojure Performance For Expensive Algorithms

Hello, I am cross-posting my Clojure question from StackOverflow. I am 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

Re: Clojure Performance For Expensive Algorithms

ava doesn't check for overflow in primitive > operations, either. > > Also use aset instead of aset-int. I don't know why, but the aset-* > operations are typically slower than aset, as long as the type hints on the > aset arguments are good enough. > > I got

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

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 S

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

VM all arrays of Objects are treated the same, regardless >> of whether those Objects are String, Integer, java.awt.Color, etc. >> >> Andy >> >> On Feb 19, 2013, at 8:46 AM, Geo wrote: >> >> One thing I don't get is that switching the type hints from

Re: Clojure Performance For Expensive Algorithms

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, Ge

Re: Clojure Performance For Expensive Algorithms

in VisualVM to > find what to optimize and how. The amount of code is about the same at > either end. > > > On Thursday, February 21, 2013 10:41:55 AM UTC+1, Christophe Grand wrote: >> >> I updated my answer on SO, with a deftype-based one that gives me an >> add

Re: Clojure Performance For Expensive Algorithms

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 you

Re: Clojure Performance For Expensive Algorithms

programming solution, which is O(M*N), but > there are O(M+N) algorithms that might be faster depending on the length > and "alphabet" of your input sequences. > > On Monday, February 18, 2013 11:16:51 PM UTC-5, Geo wrote: >> >> Hello, >> >> I

Re: Clojure Performance For Expensive Algorithms

> 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 i

Re: Clojure Performance For Expensive Algorithms

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 r

Re: Clojure Performance For Expensive Algorithms

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, Ma

Lazy sequences to replace looping?

Hello, I am just getting started with Clojure and I had a question. I have to following code: (get-rss-entry (get-rss-feeds h-res) url) The call to get-rss-feeds returns a lazy sequence of URLs of feeds that I need to examine. The call to get-rss-entry looks for a particular entry (whose :li

Re: Lazy sequences to replace looping?

Thanks. I investigated it, which led to another related question as to whether lazy seqs are always chunked (it appears not!). I posted this on stack overflow here: http://stackoverflow.com/questions/12412038/in-clojure-are-lazy-seqs-always-chunked -- You received this message because you are