Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!terminator!ebbtide.ifs.umich.edu!lee
From: lee@ebbtide.ifs.umich.edu (Lee Pearson)
Newsgroups: comp.sys.ncr
Subject: Re: Informix 4gl and C optimizer
Message-ID: <1990Dec18.215429.3605@terminator.cc.umich.edu>
Date: 18 Dec 90 21:54:29 GMT
References: <1990Dec14.035146.18882@seachg.uucp>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Organization: University of Michigan, IFS Project
Lines: 45

In article <1990Dec14.035146.18882@seachg.uucp> jalsop@seachg.UUCP (John Alsop) writes:
>I ran across an interesting problem today which might be of interest to
>other Tower users.
>
>A client has an application written in Informix 4GL.  It consists of 25
>source modules, and takes about an hour to compile on another Unix box
>comparable to the Tower. The compilation process involves generating C code
>from the 4GL source, and then compiling the C into an executable.
>
>The first try at compiling the application on a Tower 600 with 3.00.01 ran
>for over 7 hours without finishing.  No-one was too impressed.
>
>A brief analysis of the compilation of one of the modules showed that the
>actual compilation from 4GL to C to assembler took about 45 seconds.  The
>optimizer then started up and ran for about an hour!
>
>Changing the default optimization level from 2 to 0 allowed all 25 modules to
>be compiled in 40 minutes.
>
>I'm curious as to why the code generated by Informix' 4GL should cause such
>pathological behaviour of the optimizer.  Ideas anyone?
>
>-- 
>John Alsop
>
>Sea Change Corporation
>6695 Millcreek Drive, Unit 8
>Mississauga, Ontario, Canada L5N 5R8
>Tel: 416-542-9484 Fax: 416-542-9479
>UUCP: ...!uunet!attcan!seachg!jalsop


I participated in writing a large application in Informix 4GL.  What we found
was that input statements from forms with many before and after field clauses
created hugh C switch statements.  When these routines were optimized, a slow
process but never 7 hours, the resulting executable code usually contained bugs
that caused the program to crash (I suspect from a bad return address on a
corrupted stack).  We typically turned off the optimizer for all our compiles.
I should note that this was on a Tower 32/400 and 32/450 running 1.00 and 2.00
operating systems.

Lee Pearson
Institutional File System project
The University of Michigan
313-763-0606