Xref: utzoo comp.lang.c:26826 comp.lang.misc:4419
Path: utzoo!censor!isgtec!robert
From: robert@isgtec.UUCP (Robert A. Osborne)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: problems/risks ...
Message-ID: <307@isgtec.UUCP>
Date: 12 Mar 90 20:24:20 GMT
References: <300@isgtec.UUCP> <871@enea.se>
Reply-To: robert@isgtec.UUCP (Robert Osborne)
Organization: ISG Technologies Inc., Mississauga, Ontario
Lines: 55

In article <871@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>Robert Osborne (robert@isgtec.UUCP) writes:
>>I'm tired of people blithly saying that "such and such is dangerous,
>>and hence should be removed from the language" when I need such
>>things to get interactive performance.  How many people posting to
>>this group(s) are actually using C in a production environment?
>We have severe performance problems in the system I involved with,
>but I can tell you it's not because Pascal doesn't provide fall-
>throughs on the CASE statement or have expensive function calls.
>Those are simply not an issue. (This is a database application,
>so our problems are connected with the disk I/O and locking.)
If I was writing a database application, I wouldn't want to use
C either! Our product is a 3d medical imaging system, so my problems
(performance wise) are with handling short[512*512] pixel arrays.
An extra couple of cycles per pixel adds up REALLY quick.

Your article illustrates *EXACTLY* what I was complaining about,
the example of an IO bound process is meaningless, not all processes
are IO bound.  If somebody was using some subtle, neat C trick to shave
off a few cycles when the very next thing they do is access the disk,
I would say they were not a good programmer (actually I would probably
scream first).  Similarily, if they had a couple of unnecessary
function calls for every pixel processed because they didn't want
to use "messy" but valid C functionality I would also say they were
a poor programmer.  Which of the two is worse is ENTIRELY dependent
on you application.

>Working in a production does not only mean ultimate performance,
>but also acceptable reliability and correctness.
Presently our company dominates our market, mostly because
our system is fast enough to be clinically useful.  In some applications
not doing it fast enough is almost as bad as not doing it!
Analyzing the trade offs between reliability and performance
are what programmers are paid for.

>With a small application you can maybe afford to have those traps
>around to be able to gain some small percentage in execution time.
>(Which not always is worth the bucks it costs your employer to pay you
>doing it.) But when the size increases it becomes more and more
>important to keep those traps out.
In our application the precentages can be HUGH,  I can think of one
application that went from 30 seconds to 3 by using some really ugly
macros to inline routines.  At 30 its too slow to put in the product,
at 3 its a part of our demos.   It was definitly worth a couple of
days work.   Again if another couple of days got the time down to 2.9
seconds using really ugly C that was a bitch to support,  I agree,
it isn't worth it.

Sometimes performance is a consideration!  You should not judge a
language or what programming methods others use on the basis of what your
application demands.

Rob.
-- 
Robert A. Osborne   {...uunet!mnetor,...utzoo}!lsuc!isgtec!robert