Early or Lazily?

This is a discussion on Early or Lazily? within the Tech Board forums, part of the Community Boards category; Early: Do everything we need at the begining. E.g. Constructor, File Header. Lazily: Do as it required. E.g. Dynamic library, ...

  1. #1
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489

    Early or Lazily?

    Early: Do everything we need at the begining.
    E.g. Constructor, File Header.

    Lazily: Do as it required.
    E.g. Dynamic library, ...

    Is it about style?
    Is there any reason why do you do with that way?

    It is not only in programming but also in our daily life.
    Just GET it OFF out my mind!!

  2. #2
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,439
    The more I do it, the less I think there is any pattern to it.
    And that goes for daily life too.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #3
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    Is there some consideration, maybe?

    Why we would load all plugins at startup, instead of load it when neccesary?
    Just GET it OFF out my mind!!

  4. #4
    Registered User jdragyn's Avatar
    Join Date
    Sep 2009
    Posts
    92
    Depends on the needs. In a game where speed is important, having everything pre-loaded makes sense. In a spreadsheet program where most functions are rarely needed and the program is more likely to wait on the user for input, loading things only as they become necessary makes sense. If there is an equal case for either behavior then it would be a matter of style or design. The design of loading everything up front might be easier to accomplish or perhaps more extensible, or it might be the other way around.

    Kind of like going to the supermarket to buy all of the ingredients for a recipe before you begin preparing the meal. Wouldn't make sense to go to the store, buy the flour, go home, measure it out into a bowl, go back to the store to buy the eggs, etc. In fact, in most things I can think of, as long as you have the room and you know you will need the "parts", doesn't make much sense to only get some and then have to go get the rest later.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Eager
    + Common work for multiple operations needs only be done once
    + No delays when result is actually accessed
    - Long initial delay
    - Need resources to store result

    Lazy
    + Result doesn't need to be stored
    + No time is spent on unneeded operations
    - Common work gets repeated
    - Access time is longer

    Take this list and evaluate each case on its own.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Well, the procedural programming method teaches to lay out the procedures first, then to work on the details once you have the basic problem defined. That said, I tend to do things as I need them, even though I'd probably be more efficient if I stuck with procedural.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  7. #7
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    Quote Originally Posted by CornedBee View Post
    Eager
    + Common work for multiple operations needs only be done once
    + No delays when result is actually accessed
    - Long initial delay
    - Need resources to store result

    Lazy
    + Result doesn't need to be stored
    + No time is spent on unneeded operations
    - Common work gets repeated
    - Access time is longer
    Eager
    - The parameters should be known first

    Lazy
    + The parameters are dynamic

    So it's about access time, resource and ?common work??


    In CornedBee context, do things lazily is much better than eagerly because "No time is spent on UNNEEDED operations" while "Common work gets repeated" can be solved using caches.

    In what content?
    Just GET it OFF out my mind!!

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by audinue View Post
    Eager
    - The parameters should be known first
    True. But if the parameters are not known at the time of eager computation, then it's not even a choice. I was listing things that are up to the programmer's judgment.

    In CornedBee context, do things lazily is much better than eagerly because "No time is spent on UNNEEDED operations" while "Common work gets repeated" can be solved using caches.
    That's a gross overgeneralization. For example, there might be no unneeded operations in a particular case, or sufficiently few that it's not worth doing them lazily. (Lazy computation is often more complicated to implement.) Or the result of the common work could be so large that caching it is impractical. For example, let's assume we have a program that extracts information from large images and then does something with it. There are different kinds of information, and not every run needs everything. However, a part of every single information retrieval would be to transform the image into a different form (e.g. decompress). Because the image is very large, caching that different form might simply be impractical, especially if the memory is needed elsewhere. Or you might have enough memory to cache the image, but CPU cache locality still says it's better to do only one scan over the image data and incorporate the retrieved information into several computations at once. So it's better to compute all information at once, eagerly.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,439
    Quote Originally Posted by audinue View Post
    So it's about access time, resource and ?common work??
    It seems to me you are trying to find a commonality and then extrapolate from there what's the best approach. But there is none. That's simply not the best way to evaluate the need for one over the other.

    The approach has to be defined on a case by case basis. And even then, what might be a desirable approach in terms of performance or resource usage, may not be in terms of code maintainability or expansibility, or vice-versa, or in any other combination. Meaning, more often than not you are left with a paradigm you need to resolve. And the best option can often be described as "Pick your favorite poison".
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    It's also not black and white. Sometimes there are hybrid solutions. You could wait until the first access to one of a group of properties, and then compute them all at once. You could do part of the computation eagerly, and another part lazily.
    Another consideration is this: usually, eager vs lazy is a question of implementation, which leaves the interface untouched. However, if the computation can fail, then in the eager case the initial calculation may fail, while for lazy implementations it's the result fetching that would fail, so you've got a change in the interface. This may sometimes force you to do a computation eagerly, because you cannot afford it failing once you've committed the the larger operation that needs the result.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Segmentation Fault, very early on.
    By habicabi in forum C Programming
    Replies: 1
    Last Post: 09-18-2009, 01:53 PM
  2. Late or early binding?
    By Sharke in forum C++ Programming
    Replies: 4
    Last Post: 08-17-2009, 12:28 PM
  3. Hooked Procedure Early Return In/External Trigger
    By n00b3 in forum Windows Programming
    Replies: 4
    Last Post: 06-29-2008, 05:37 PM
  4. How to avoid console program crash when terminated too early
    By Xargo in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 10-03-2007, 04:43 PM
  5. Zelda comes out early
    By Scourfish in forum A Brief History of Cprogramming.com
    Replies: 14
    Last Post: 03-28-2003, 02:44 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21