Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)

by diotalevi (Canon)
on Jun 25, 2003 at 23:27 UTC ( #269052=note: print w/ replies, xml ) Need Help??


in reply to Re: (On Speed Diff, etc.) Closure on Closures (beta)
in thread Closure on Closures

Your object method calls are slower because the add on ISA lookup/maintenance (just because it is a method), a variable dereference and a hash lookup. The base closure is just a function and postincrement. It makes sense for one to be slower, both perform the same task, one has to do a bit more janitorial work. Consider though, that your closure might be heavier in memory requirements. Does any of this really matter? Probably not. This is not the sort of thing I worry about. Generally my decision on how to organize my data is driven by other requirements than method call overhead. In fact, it always is. Except for once when I was doing a really, really big batch job. Then I used plain functions.


Comment on Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
by chunlou (Curate) on Jun 26, 2003 at 01:50 UTC
    In short, (in Perl at least) closure is faster than object due to less dereferencing overhead but could be slower due to larger memory requirement? (In the test, the edge of closure over object was diminishing and even reversed when the tasks were getting more "heavy-duty.")

    Different question, if I may. I want to focuse on Design, as opposed to Programming.

    How would you characterize and procedurize a "functional design process" (if there is such a thing). Like a user manual on Design: the Functional (or Closure) Way.

    I hope it's self-evident that design and programming are not always an integrated process. Many people program in Java the imperative or procedural way pretty much, nothing so OO about the design of the codes.

    On the other hand, a design framework could be applied more generally even when the tools are not integrated with it. Like, OO Design is a good framework to guide your thinking process to characterize and generalize some human verbal requirements into classes. For instance, you could think of a Webpage being a class and the stored procedure associated with it being methods, even though HTML, SQL, etc are not OO.

    Besides the characterization of the process, what would be the examples constrasting the closure/functional of design versus the other whatever ways, along with the advantages--design-wise or conceptual--such as being more succinct, flexible, insightful, etc? (Like, in physics, some people do things the group-theoretic way vs. the good old calculcus way; in economics, game-theoretic vs others. They produce different insights into the same problems and sometimes even different conclusions.)

    Take the scripts in the test as examples. Closure counter certainly looks like a cleaner design (or model); object is probably an overkill in this case. With the Turtle, if we need more "methods," object seems like a natural way to go. With directory iterator, I really have no preference towards either.

    Thanks.

    _______________________
    Update: As a afterthought, maybe some examples on translating some existing OO design/code into closure one (if applicable) would be pedagogically more instructive? Since I suppose more people can relate to OO than closure.

      In short, (in Perl at least) closure is faster than object due to less dereferencing overhead but could be slower due to larger memory requirement? (In the test, the edge of closure over object was diminishing and even reversed when the tasks were getting more "heavy-duty.")
      No, larger just means larger (unless you get so large you swap). Heavy use of closures would make me at least consider memory usage.

      How would you characterize and procedurize a "functional design process" (if there is such a thing). Like a user manual on Design: the Functional (or Closure) Way.
      I read two distinct thoughts in the rest of your question. Design by documentation and programming style. The programming style question is likely best answered by pointing you to Why I like functional programming. My own coding style is largely procedural for the smaller cases, object oriented for the larger picture with plenty of functional goodness. Most of my exposure to logical programming comes from SQL and XSLT (which I adore). The point is that for common, every day programming there is a lot to be gained by being flexible and drawing from many disciplines.

      It lets me get my work done and done right.

      As for programming by documentation, I'm playing with that right now. For the project I'm on I've been writing the documentation for processes that the code implements and then just like mortar, filling actual code in after the fact. So far its a dream. I think other people call this ``Design by Contract'' but I couldn't swear to that. In fact, there's a module Class::Contract which purports to help you write code that way (though if you read just the documentation you won't understand DoC).

        My question was also intended to be a pedagogical one, though I might or might not have conveyed that notion.

        Perhaps I rendered the wrong idea when I used words like "characterize" or "procedurize" (I don't know if such word even exists).

        Design is a creative process. I don't think anyone can "mechanicalize" (another makeup word?) it. But people certainly have explicit or implicit theories behind their minds guiding their thinking and design process.

        Perhaps what I'm trying to ask is, what are the guiding theory of "closure"?

        Stated "theories" accompanied with examples are important when teaching someone something new, just as foreign language teachers teach grammar. People who already speak the language don't think grammar. Programmers who already master the trade don't think of what paradigm, theory or style they're actually employing.

        But for a student, he might be more explicitly and discretely thinking of "encapsulation," "interfaces," "inheritance," etc. one by one, rather by utilizing every appropriate thing dexterously without thinking of all those "labels." It's just a natural learning process.

        Thanks.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://269052]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2014-07-31 04:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (244 votes), past polls