I think that the answer is, it depends, and, there might be some surprises in store.
In my own use, I found multimethods collapse in performance as a result of changes to the interface hierarchy in the library I was using (my tests cases went from 45s to over 4mins). I circumvented this by fiddling with the dispatch function, so that it returned ONLY classes that exactly matched one of the ones in the multi-method, and memoizing the look up of these classes. In effect, this closes down the multi-method, so it can no longer be freely extended. This dropped the time of my test cases dramatically. How widely applicable these results are, I do not know, as I never got down to the mechanistics underneath. Still, my conclusion is, you might want to test things out first! My full set of experiments are here... http://www.russet.org.uk/blog/3007 Timur <timurha...@gmail.com> writes: > Hi everyone, > > There are situations where I want to dispatch functions using based on > their certain properties. I can also use case statements instead but it > looks more coupled and more change is required if I want to add new types. > > What I want to ask is if I need to avoid using multi-methods for > performance reasons? I read somewhere that they are not really fast but the > posts were old and the performance might have been improved in between. > Should I favor case and cond branches instead of defmulti when I need > performance? > > Thanks for your help!!! -- 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/d/optout.
