Setting that one
(set! *warn-on-reflection* true)
Helped a lot in my simulation model to find out where clojure/java
were having trouble. It pointed out that one of my main functions was
causing trouble, and could do with a bit of typehinting.
(defn #^Short find-all-epi
"turns the rx and string into a matcher, and finds all epitopes
for
this string. Most cpu-intensive component of the
model.
* typehinting reduced cpu-time to 60% of original function."
[#^dk.brics.automaton.RunAutomaton rx #^String string]
(let [matcher #^dk.brics.automaton.AutomatonMatcher (.newMatcher rx
string)]
(count (take-while #(= true %) (repeatedly (fn [] (.find
matcher)))))))
The speed of clojure, as far as I can tell, is quite good. It might
need optimization for pure brute-force calculations like the project
you described, but the majority of my model gets called once every 2-3
minutes, and just a few bits I actually needed to look at the
optimizations that I needed.
There are a few other types of optimization available for clojurans,
but I have little experience with those yet.
Your code also doesn't look very clojure-like, with that large number
of nested loops, but I'm not that much a wizard in clojure yet, or
familiar with the problem, and the looping might be the best thing to
do.
You can at least make a function of
(+ (* (first a) (first a))
(* (first b) (first b) (first b))
(* (first c) (first c) (first c) (first c)))
as you have now spelled that out four times in your code.
(defn sumthingy [a b c]
(+ (* 2 (first a) (* 3 (first b)) (* 4 (first c))))
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
