Re: Cost of creating objects?

Kevin McMurtrie <mcmurtrie@pixelmemory.us> writes:


  As a corollary to ?Don't try to fix it if it ain't broke??
  and ?You ain't gonna need it.?:

  Either the completed product will be observably too slow or not.

  If it is /not/ observably too slow,

      any further work into optimization (which usually reduces
      code portability and quality) will be a waste of time.
      (And possibly work already done in this direction so far
      already was a waste of time.)

  If it /is/ observably too slow,

      then, using reasoning and possibly a profiler, one can
      identify possible regions of code eligible to further
      optimization efforts. The beauty of fixing something
      that actually /is/ broken is that it /will be observable/
      whether the modifications make the product faster,
      because we already have asserted that it is observably
      too slow, so it also will be observable when this
      condition is being changed (And possibly work already
      done in this direction before was a waste of time,
      because it was optimization at the wrong places.)

  Of course, one can still choose to write code in the way
  most efficient in the first place, whenever one can see that
  this is /obviously/ (with certainity) the way most efficient,
  and it comes with little additional cost.

  ? ?ain't broke? = ?is not broken?, ?is not broken? is more
  common, but I remember it this odd way: ?ain't broke?.