From: Nathaniel Calloway
Subject: Performance of CLOS over closures
Date:
Message-ID: <ufxtb2m6h.fsf@cornell.edu>
So, I never use CLOS. Don't get me wrong, I like OOP alot, its jsut
that when I'm in a "functional" mindset I tend to avoid it. However,
whenever I need something objecty and stateful, I normally just write
a little closure that for all intents and purposes is equivalent to an
object.
My question is: How do closures compare to CLOS in terms of
performance? Am I being smart by avoiding the overhead of an object
system, or are closures expensive enough that there is no net gain?
For all I know, I could be implementing the same code that is in CLOS
each time I put together a closure. I've never gotten into CLOS enough
to figure out. I want to know because if I can implement things simply
in CLOS, I might save myself from writing some boiler plate.
Thanks,
Nat
Nathaniel Calloway <····@cornell.edu> writes:
> So, I never use CLOS. Don't get me wrong, I like OOP alot, its jsut
> that when I'm in a "functional" mindset I tend to avoid it.
Common Lisp is not an especially functional programming language.
> However, whenever I need something objecty and stateful, I normally
> just write a little closure that for all intents and purposes is
> equivalent to an object.
Sure, a closure is an object. A CLOS instance is an object. An integer
is also an object.
CLOS isn't just about objects with state, it's also (and more so)
about generic functions, which have some really nice non-obvious (to
someone used to message-passing style) features. Effective methods
that are created based on the types of all required arguments,
different method combinations, :before :after :around methods,
call-next-method, etc. are all useful tools for solving problems.
> My question is: How do closures compare to CLOS in terms of
> performance? Am I being smart by avoiding the overhead of an object
> system, or are closures expensive enough that there is no net gain?
Closures might be faster than using CLOS for simple things. If you
want some of the non-simple incredibly useful features of CLOS, you
will find it pretty hard to do with closures without re-implementing
fast, mature parts of CLOS, with results that will probably not be
very fast or mature.
> For all I know, I could be implementing the same code that is in CLOS
> each time I put together a closure. I've never gotten into CLOS enough
> to figure out. I want to know because if I can implement things simply
> in CLOS, I might save myself from writing some boiler plate.
A lot of people start out rejecting CLOS without knowing much about it
because they don't like some aspect of mainstream object-oriented
programming, or because they think Paul Graham's books are good for
learning Common Lisp. This is a mistake! Don't fall for it
yourself. CLOS is a little complex, and takes some time to learn, but
it's worth it. Sonya Keene's book on CLOS should help speed up the
process.
Zach
Nathaniel Calloway wrote:
> So, I never use CLOS. Don't get me wrong, I like OOP alot, its jsut
> that when I'm in a "functional" mindset I tend to avoid it. However,
> whenever I need something objecty and stateful, I normally just write
> a little closure that for all intents and purposes is equivalent to an
> object.
>
> My question is: How do closures compare to CLOS in terms of
> performance?
There is no comparison. CLOS is a bloated pig by comparison, so do not
be mean to CLOS, just go with your closures as long as they are easy to
live with code-wise. When you find yourself bending yourself into funny
shapes you can look at CLOS.
> ...Am I being smart by avoiding the overhead of an object
> system, or are closures expensive enough that there is no net gain?
Geez, what are you doing over there, protein-folding? ie, Do you
actually have some compute-intensive application? Everyone wlse around
here will offer advice and tell you what to do without asking that, but
it matters. My guess is that the performance difference while relatively
great is inconsequential to your app, so ease of coding is the only
thing to think about (and closures might still win).
> For all I know, I could be implementing the same code that is in CLOS
> each time I put together a closure. I've never gotten into CLOS enough
> to figure out. I want to know because if I can implement things simply
> in CLOS, I might save myself from writing some boiler plate.
Post some code?
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.
"My sig is longer than most of my articles."
-- Kenny Tilton
From: Nathaniel Calloway
Subject: Re: Performance of CLOS over closures
Date:
Message-ID: <u63u695qx.fsf@cornell.edu>
Ken Tilton <···········@optonline.net> writes:
>> My question is: How do closures compare to CLOS in terms of
>> performance?
>
> There is no comparison. CLOS is a bloated pig by comparison, so do not
> be mean to CLOS, just go with your closures as long as they are easy
> to live with code-wise. When you find yourself bending yourself into
> funny shapes you can look at CLOS.
>
Thank you, thank you, thank you for actually answering the question
instead of saying that all that matters is the clearness of my
code. Its not that maintanability or ease of writing isn't important,
but I'm sick of it being the answer to every single solitary question
about any programming language, ever.
>> ...Am I being smart by avoiding the overhead of an object
>> system, or are closures expensive enough that there is no net gain?
>
> Geez, what are you doing over there, protein-folding? ie, Do you
> actually have some compute-intensive application? Everyone wlse around
> here will offer advice and tell you what to do without asking that,
> but it matters. My guess is that the performance difference while
> relatively great is inconsequential to your app, so ease of coding is
> the only thing to think about (and closures might still win).
Actually...you were pretty close. I'm writing a system to
simulate/parse biological networks (proteins, metabolites, etc.) The
number of computations scales exponentially with the size of the
database. This is for non-CS research purposes, so you can imagine the
constraints that puts on the project: there's not much manpower, but I
don't want to sacrafice too much for ease of coding because I need to
publish in a timely matter. So there is a big diffrence in a
simulation running overnight or over 2 days, but speed is not the final goal.
>> For all I know, I could be implementing the same code that is in CLOS
>> each time I put together a closure. I've never gotten into CLOS enough
>> to figure out. I want to know because if I can implement things simply
>> in CLOS, I might save myself from writing some boiler plate.
>
> Post some code?
Not until I publish ;).
-Nat
Nathaniel Calloway wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>>My question is: How do closures compare to CLOS in terms of
>>>performance?
>>
>>There is no comparison. CLOS is a bloated pig by comparison, so do not
>>be mean to CLOS, just go with your closures as long as they are easy
>>to live with code-wise. When you find yourself bending yourself into
>>funny shapes you can look at CLOS.
>>
>
>
> Thank you, thank you, thank you for actually answering the question
> instead of saying that all that matters is the clearness of my
> code. Its not that maintanability or ease of writing isn't important,
> but I'm sick of it being the answer to every single solitary question
> about any programming language, ever.
>
>
>>>...Am I being smart by avoiding the overhead of an object
>>>system, or are closures expensive enough that there is no net gain?
>>
>>Geez, what are you doing over there, protein-folding? ie, Do you
>>actually have some compute-intensive application? Everyone wlse around
>>here will offer advice and tell you what to do without asking that,
>>but it matters. My guess is that the performance difference while
>>relatively great is inconsequential to your app, so ease of coding is
>>the only thing to think about (and closures might still win).
>
>
> Actually...you were pretty close. I'm writing a system to
> simulate/parse biological networks (proteins, metabolites, etc.) The
> number of computations scales exponentially with the size of the
> database. This is for non-CS research purposes, so you can imagine the
> constraints that puts on the project: there's not much manpower, but I
> don't want to sacrafice too much for ease of coding because I need to
> publish in a timely matter. So there is a big diffrence in a
> simulation running overnight or over 2 days, but speed is not the final goal.
As Kent was saying, CLOS does not necessarily mean standard class. I
think (guessing from what you have said) you might do best with
defstruct. defstructs are quite lightweight (basically vectors with
syntactic sugar that costs nothing). Then you get typed data in (if you
like) a singly-inheritant hierarchy, you can use typecase or GFs
specialized on them, they inspect easily, they get function accessors
(not GFs) -- a perfect balance of HLL power and performance.
I tried implementing my famous Cells hack lotsa ways and thought
closures would be much faster, turns out they were much slower than
structs as well as a PITA to use after a certain point.
hth,kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.
"My sig is longer than most of my articles."
-- Kenny Tilton
Nathaniel Calloway <····@cornell.edu> writes:
> So, I never use CLOS. Don't get me wrong, I like OOP alot, its jsut
> that when I'm in a "functional" mindset I tend to avoid it. However,
> whenever I need something objecty and stateful, I normally just write
> a little closure that for all intents and purposes is equivalent to an
> object.
>
> My question is: How do closures compare to CLOS in terms of
> performance? Am I being smart by avoiding the overhead of an object
> system, or are closures expensive enough that there is no net gain?
It depends on what you mean by "for all intents and purposes is
equivalent to an object." Who can tell from that what your closures do?
Anything from a struct duplication to (funcall object 'message) is a
reasonable guess.
Anyway, the right thing to do is to profile your code against equivalent
CLOS code. If the speed difference is great enough in your favor to
matter and you don't need inheritance or multi-methods, then you might
as well stick with closures.
> For all I know, I could be implementing the same code that is in CLOS
> each time I put together a closure. I've never gotten into CLOS enough
> to figure out. I want to know because if I can implement things simply
> in CLOS, I might save myself from writing some boiler plate.
You can always automate the boiler plate if you prefer closures.
Nathaniel Calloway wrote:
> So, I never use CLOS. Don't get me wrong, I like OOP alot, its jsut
> that when I'm in a "functional" mindset I tend to avoid it. However,
> whenever I need something objecty and stateful, I normally just write
> a little closure that for all intents and purposes is equivalent to an
> object.
>
> My question is: How do closures compare to CLOS in terms of
> performance? Am I being smart by avoiding the overhead of an object
> system, or are closures expensive enough that there is no net gain?
> For all I know, I could be implementing the same code that is in CLOS
> each time I put together a closure. I've never gotten into CLOS enough
> to figure out. I want to know because if I can implement things simply
> in CLOS, I might save myself from writing some boiler plate.
The primary focus of coding should be clear code, not imaginary
efficiency concerns.
There may be slight differences in performance, but whether they matter
or not at a large scale is impossible to predict. Tune your code only as
soon as you know that you have a bottleneck, and then only worry about
that bottleneck.
Apart from that, use the constructs that most clearly express your
intent and best suit your own preferences in programming style.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
P� Thu, 24 Apr 2008 19:32:38 +0200, skrev Nathaniel Calloway
<····@cornell.edu>:
> So, I never use CLOS. Don't get me wrong, I like OOP alot, its jsut
> that when I'm in a "functional" mindset I tend to avoid it. However,
> whenever I need something objecty and stateful, I normally just write
> a little closure that for all intents and purposes is equivalent to an
> object.
>
> My question is: How do closures compare to CLOS in terms of
> performance? Am I being smart by avoiding the overhead of an object
> system, or are closures expensive enough that there is no net gain?
> For all I know, I could be implementing the same code that is in CLOS
> each time I put together a closure. I've never gotten into CLOS enough
> to figure out. I want to know because if I can implement things simply
> in CLOS, I might save myself from writing some boiler plate.
>
> Thanks,
>
> Nat
Well first forget about efficiency and focus on clarity when you design it.
To many issues will come up along the way and premature optimisation will
probably just make you miss opportunities for better code that is clearer
and often more efficient.
Closures behave more like modules in languages like Modula or packages in
ADA (ADA 84 that is with out the new object oriented constructs.)
They can provide clearer and more succinct code for simple cases and
require less typing.
This is a few cases where you might want a class instead.
You need the functions to work on many objects.
You need the code to be reentrant.
You would like to inherit properties.
You want polymorphism. (example. You want a collector to work on all
widgets and you have many types of widgets)
My argument for trying a class first is that the needs are not always
clear when you start programming and while you can easily make a class do
the same as a closure you cant make closure's behave like classes (without
a huge effort). So when in doubt side why not just use classes?
--------------
John Thingstad