On Jun 22, 3:40 pm, David Gourley <d...@NOSPAM.gourley.plus.com>
wrote:

Make sure you use StringBuffer instead of Strings, if you're doing
much with text ;)

-------
Ben Coe
http://www.plink-search.com

    ... and yet, there are cases where timeliness can be
more important than accuracy.  In a real-time setting, for
example, a rough approximation that is available NOW may be
of some use, while a perfect answer would be worthless a
millisecond later.

    In my days doing radar data-processing for air traffic
control, I recall another engineer observing that you can't
radio all the pilots and tell them to hold still while the
computer works through its backlog ...

But there's good optimization and bad optimization.  I had a boss refuse to
let me fix an O(n-squared) algorithm and insisted that I optimize without
changing the algorithm.  He then tried to withhold my fee because the program
was too slow.

The problem was that I wanted to fix the algorithm (good optimization) and he
wanted to speed up the bad algorithm (bad optimization).

When the company realized that I had provided a solution, trained the other
programmer in it, and that someone else had caused the problem, I got my fee.

The problem with saying, "I want my program to be efficient" is that people
focus on micro-optimization.  You might buy 10% improvement by
micro-optimization after the fact, but of course the JVM is probably already
taking care of that kind of optimization for you.  You might buy 10,000%
improvement over some data sets by the correct choice of algorithm in the
design phase.

That rule is too prescriptive for my taste. You need to know a lot more
about the problem being solved, and in particular about data volumes and
behavior, before making that decision. As examples:

- There may be hidden gotchas. For instance, quicksort is only faster
  than shellsort if swapping items is more expensive than comparing
  them.

- If you're using a binary search on a large data set and adding missing
  items rather than just returning "not found", then modifying the
  binary search to say where the missing item should be and using that
  information to slot the new item into the right place may well be
  faster than using a sort. The best solution will depend on the miss
  percentage.

- if the data set is very large and/or searches have a high miss
  frequency you don't use either a binary search or any type of sort:
  you use a black-red binary tree if inserts tend to cluster, the
  growth is large compared to the initial data set or if you need to
  read out the data set in key sequence. Otherwise a hashtable may be
  better.

In short, spend time understanding the problem and its behavior before
designing or implementing anything. Build well-instrumented throw-away
models if you need to.

Well put.

For most operations (e.g. sorting) use system
or library provided routines. :-)

  BugBear

That depends on how you do it, but yes, I can see what you're saying. Tuning
an n-tiered system can be quite complex. Luckily I only deal with a subset of
the whole system.

Eric