On 2010 Apr 28, at 11:04 PM, Rich Hickey wrote:
It is an important aspect of Clojure that, in general, performance
guarantees are part of the semantics of functions. In particular,
functions are not supported on data structures where they are not
performant.
Understood. That isn't the point/question I was trying to raise.
Again, back to the demo of protocols in Stuart's video, the question
isn't "is seq-contains? potentially lying about its performance" but
"why shouldn't any function, including seq-contains? be as fast as it
can be, when it can be?"
...<most of the rest is a slight tangent from my fundamental question,
however interesting it might be for other reasons>...
And people have been rolling their own includes? etc for this job.
Now everyone can use seq-contains? for that. Its poor performance is
indicated by its name and documentation. Should someone try to take
a piece of code based on seq-contains? and try to scale it, they
will see that function as an obvious bottleneck.
Really? We've known for a long time that people suck at guessing where
programs have performance bottlenecks (1), and that taking a premature
optimization attitude "obvious bottleneck" is wrong headed (2).
(1) consing is bad!
(2) 20G of garbage per second and the CPU utilization barely breaks
10%? Hmmm, I guess consing isn't so bad and that thinking "consing is
bad" is just another old, preconceived notion proved wrong, so that
'obvious bottleneck' turns out not to be so obvious after all.
Shouldn't seq-contains? be parallelizable, esp. vectors where you can
easily create O(1) slices... or use other techniques when sequences of
certain kinds might have other exploitable properties?
What is the purpose, goal, design-rationale of not making seq-
contains? fast on maps or sets?
Clojure is not particularly duck-type-y, in general things are not
unified by the presence of same-named functions but by underlying
shared abstractions. Just because protocols can be used to make
things reach many types doesn't mean they should be used to unify
things that aren't uniform.
Are saying that seq-contains? will not work on sets and maps because
they aren't uniform w.r.t. sequences or that they are uniform, but
protocols won't fit here as an optimization technique because _____
(being brand new, I don't know all the subtleties of protocols), or ???
If you want to get a feel for how the abstractions in Clojure are
organized, have a look at the slides in the middle of this
presentation (about 30 pages in):
http://clojure.googlegroups.com/web/tutorial.pdf
Actually I have seen those slides already, but had lost track of where
I had found them, thanks for the reminder pointer.
While you may not agree with it (and everyone disagrees with
contains? :), at least the design is a considered one
I generally agree with the design Clojure embodies as an outlook :).
As to contains? ... I agree with Mark Engelberg's detailed analysis
and conclusions.
-Doug
--
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
