Performance of CLOS over closures
in [Lisp]
|
Prev: Brand Watches Baume & Mercier Men's Hampton Chronograph Automatic Watch #8344 Discount, Swiss, Fake
Next: Lisbox on ubuntu
From: Nathaniel Calloway on 24 Apr 2008 13:32 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
From: Zach Beane on 24 Apr 2008 15:31 Nathaniel Calloway <ntc6(a)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
From: Pascal Costanza on 24 Apr 2008 15:45 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/
From: Paul Donnelly on 24 Apr 2008 16:14 Nathaniel Calloway <ntc6(a)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.
From: Ken Tilton on 24 Apr 2008 16:30
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 |