>From what I can tell, Clojure uses persistent hash sets inside of set. This
can be fixed by replacing set with (into #{} data). Into uses transients
internally and should be much faster.I don't know Scala, but from I can tell, Scala is using mutable collections. I think the combination of these two things (immutable collections plus lack of transients) could be causing some performance impact. I wouldn't expect it to be 1000x but it's a starting place. Timothy On Wed, Oct 23, 2013 at 6:36 AM, Paul Butcher <p...@paulbutcher.com> wrote: > On 23 Oct 2013, at 13:18, Timothy Baldridge <tbaldri...@gmail.com> wrote: > > Great! you have a profiler, use that. Find the hotspots, use YourKit to > find where the .cons is being called from, find things to optimize, and go > from there. This is exactly the same process I would use any optimizations > I attempted. > > > I fear I may have failed to convey the question I'm trying to answer. > > I'm sure that I could create a faster solution in Clojure - that's not the > question I'm trying to answer though. > > What I'm trying to answer is why the *exact same* algorithm implemented in > Scala is 1000x faster. > > As far as I know, the Scala version of the algorithm creates exactly as > many sets and performs exactly as many set operations as the Clojure does. > But the Clojure version is 1000x slower. That strikes me as very strange > and worth getting to the bottom of? > > I have, of course, looked at the result of the profiler. And what it seems > to be saying is that set operations in Clojure are ruinously slow. I'm not > sure that I believe that though - I can't think of any reason why Clojure's > sets should be 1000x slower than Scala's? So I'm asking for the help of > this list. > > Of course, I can't rule out the possibility that I've failed to convert > the Scala version to Clojure and they're actually implementing very > different algorithms - but I've had several people look at the > implementations and confirm that they appear to be the same. Nevertheless, > if there is a problem there, I'd also be interested to find it as I'm sure > that it will teach me something. > > -- > paul.butcher->msgCount++ > > Snetterton, Castle Combe, Cadwell Park... > Who says I have a one track mind? > > http://www.paulbutcher.com/ > LinkedIn: http://www.linkedin.com/in/paulbutcher > MSN: p...@paulbutcher.com > AIM: paulrabutcher > Skype: paulrabutcher > > -- > -- > 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. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
