Re: The great Java showcase (re: 2nd historic mistake)

[Dave Sparks <Dave.Sparks@sisyphus.demon.co.uk>]

>>>>> "MC" == Mike Charlton <mikechar@nortel.ca> writes:

  MC> Dave Sparks <Dave.Sparks@sisyphus.demon.co.uk> writes:
  >> >>>>> "MC" == Mike Charlton <mikechar@nortel.ca> writes:
  >> 
  MC> ...
  >>
  MC> I have worked with both large C++ projects and large projects using a
  MC> proprietary language with automatic memory management.  Yes, with C++
  MC> we spent a lot of time thinking about memory.  However, using
  MC> automatic memory management, we spent a lot of time thinking about
  MC> performance.  I'd say it's a bit of a toss up.  No one solution will
  MC> work well for every problem.
  >>  Are you saying that when you used C++ you spent so much time on
  >> memory management that you couldn't afford to think about performance?

  MC> I'm not sure if that was meant to be a rhetorical question, but in
  MC> case it wasn't -- the answer is "No".  We just didn't need to spend
  MC> very much time tweaking performance.  My point was that automatic
  MC> garbage collection makes life easier for you.  But it doesn't come
  MC> for free.  You *can* overcome performance difficulties, but I figure
  MC> it takes about as much effort as memory stuff using C++ (IMHO, anyway
  MC> -- YMMV).

The question _was_ rhetorical - the point being that when you have
one _huge_ problem, the other, smaller, problems disappear into
the background and can get forgotten.

We've been using a byte-coded interpreted language with mark-sweep
garbage collection for over ten years, and the GC costs are
typically about 1% of the total.  Individual GCs take less than
0.1 seconds with a 2Mb heap on a SUN SparcStation 5, which is not
a problem in our context.  We used to have performance problems,
but we solved them by re-engineering the application (delivering
the 10::1 improvement we'd had to promise to get the funding).
It's doubtful that this product would have been written in C or
C++, but if it had been I don't think it would ever have met our
current performance expectations.

We also have C and C++ code where memory management is a very
difficult problem, partly because some of the code involved is not
under our control.  This area also needs re-engineering, because
the risk of memory leaks is unacceptably high.  This
re-engineering will not be easy.

Java performance does seem to be poor at the moment, but I expect
it to improve.  Remember that at one time performance was cited as
the reason for routinely using assembly code rather than a
high-level language.  This claim is uncommon today, and I expect
to see a similar change in attitude over the choice of
fully-compiled or compiled-and-interpreted languages.

I do know of one case, from twenty years ago, where two versions
of a COBOL compiler were written simultaneously by two separate
teams.  One version was written in assembly code, while the other
used a purpose-designed compiled-and-interpreted language, which
was developed as part of the project (and never used for any other
purpose).  Each team beleived that its method was the better one,
and was determined to prove it.  When the initial versions of the
copilers were compared, the assembly-code version was faster.  A
month later, the compile-and=interpret team, using the
instrumentation that the interpreter made possible, had improved
their compiler's performance enough to beat the assembly-coded
version (where performance improvements could not be accurately
targeted).

(The requirement was to replace an earlier COBOL compiler badly
written by assembly-code programmers unwillingly using a
high-level fully-compiled language.)

-- 
Dave Sparks, Staffordshire, England