[Klug-general] Obscure C at saturday's meeting

David Halliday david.halliday at gmail.com
Wed Dec 1 14:23:31 UTC 2010


In many contemporary cases (I have seen some examples otherwise) the cost of
extra hardware to run a heavy application is lower than the cost of a
developer to optimise code.

Especially when optimising the code makes that code harder to maintain or
causes the next developer who looks at it days lost in understanding what is
going on.

If optimisation across the board increases the man hours by one month and
then increases the time for a new developer to understand it then you have
covered some significant hardware upgrades (Lets face it a stick of RAM
costs less than one day of contractor time).

TCO rears its interesting and confusing head.

The obvious exceptions to this are things like hardware drivers and the
difference between highly optimised code and badly (sometimes this is semi
accidental) written inefficient code (Recently had an application using very
high amounts of memory because it was loading thousands of large objects
when it only needed to load an ID and one other attribute).

On 1 December 2010 14:12, Mike Evans <mike at tandem.f9.co.uk> wrote:

>
>> OK I understand that in the scheduler you want good performance and
>> compact code to get the most out of it, but some things were never meant
>> to be written.
>>
>>  This may have been true once - but hasn't been so for a long time.  This
> is because an optimising compiler will produce the same or better machine
> code from simply written, well structured and legible program code.
>
> I remember (about 18 years ago) in a quick panic wanting to slow something
> down and just added:
>
> for (i=0, i<1000, i++) /* do nothing */;
>
> Yes - I know I should have used sleep(), but never mind.  This didn't make
> the code slow enough, so I changed it to:
>
> for (i=0, i<1000000, i++) /* do nothing */;
>
> and it didn't take any longer.  When I stopped the compiler at the assembly
> stage and looked at the machine code what the compiler had actually done was
> the equivalent of:
>
> i=1000000;
>
> Served me right really.  Valuable lesson though: write the code as clearly
> as possible and let the compiler optimise.  It will probably do a better job
> than me, and will introduce fewer bugs in the process.
>
>
>
> _______________________________________________
> Kent mailing list
> Kent at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/kent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/kent/attachments/20101201/1149f3bb/attachment-0001.htm>


More information about the Kent mailing list