Converting 4GL to Unix-C/SQL
Steve W. Grist
one who has, I would like access to the replacement source code for the 4GL
calls. I am interested in doing this for performance reasons. Any relevant
discussion is appreciated.
Walt Hultgren {rmy}
writes:
>Has anyone out there converted 4GL to Unix-C and SQL.
>
Before committing to such a conversion, I would take a *detailed* look at
the structure of the programs you are going to convert. At least inspect
some of your worst and least offenders.
This is because converting to C will have no effect on many of the things
that an I4GL program does. This is probably also true of any vendor's
DBMS product that uses a client/server architecture.
First, converting the client from 4GL to C will have no effect on the
database engine (server). Further, many of the operations that we tend
to think of as "in-line" 4GL code are performed by calls to pre-compiled
vendor supplied functions. These would also be unaffected.
Then there is the consideration that your programs may alread be in C if
you have the "c4gl" version of I4GL -- not pretty C, but C nonetheless :-).
If you have the RDS version, it would still be worth your time to do some
benchmarking.
Of course there are programs whose performance could be greatly improved
by being converted from 4GL to C, but I would not presume that such a
conversion would be any kind of panacea.
If you are having performance problems with Informix-4GL programs, perhaps
you could post more details, such as what specific Informix utilities you
are using, platform, OS, etc. If your original question was more generic
than just applying to Informix, most of the above comments still hold.
Hope this helps,
Walt.
--
Walt Hultgren Internet: wa...@rmy.emory.edu (IP 128.140.8.1)
Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt
954 Gatewood Road, NE BITNET: walt@EMORY
Atlanta, GA 30329 USA Voice: +1 404 727 0648
Harry Bochner
wa...@mathcs.emory.edu (Walt Hultgren {rmy}) writes:
|> This is because converting to C will have no effect on many of the things
|> that an I4GL program does. This is probably also true of any vendor's
|> DBMS product that uses a client/server architecture.
|> Then there is the consideration that your programs may alread be in C if
|> you have the "c4gl" version of I4GL -- not pretty C, but C nonetheless :-).
|> If you have the RDS version, it would still be worth your time to do some
|> benchmarking.
I'll second Walt's remarks, and add this:
When we switched from c4gl to RDS, the users did not notice _any_ visible
degradation in performance, even though we were going from a compiled language to
an interpreted one. I expect that this would be true for most programs that are
more bound by database operations than internal computations, and I think this
situation is typical for 4GL programs.
Of course, there are applications that _are_ bound by internal computations
rather than by database operations, and in this case you don't want those
internal computations to be written in 4GL. But rather than translating the
whole program to C, you're probably better off writing those compute-bound
operations as C functions, and calling those functions from the 4GL code.
This could save a lot of headaches: if you don't get the C calling sequences
to the Informix libraries exactly right, ugly things are likely to happen.
And those calling sequences are subject to change from one version of Informix
to the next.
--
Harry Bochner
boc...@das.harvard.edu
Will Hartung - Master Rallyeist
> wa...@mathcs.emory.edu (Walt Hultgren {rmy}) writes:
> |> This is because converting to C will have no effect on many of the things
> |> that an I4GL program does. This is probably also true of any vendor's
> |> DBMS product that uses a client/server architecture.
> ....
> |> Then there is the consideration that your programs may alread be in C if
> |> you have the "c4gl" version of I4GL -- not pretty C, but C nonetheless :-).
> |> If you have the RDS version, it would still be worth your time to do some
> |> benchmarking.
>
> I'll second Walt's remarks, and add this:
> When we switched from c4gl to RDS, the users did not notice _any_ visible
> degradation in performance, even though we were going from a compiled
> language to an interpreted one. I expect that this would be true for most
> programs that are more bound by database operations than internal
> computations, and I think this situation is typical for 4GL programs.
What we have found is that the compiled 4GL gives basically two
significant benefits over RDS, and performance doesn't really make
this list (although if you look at the CPU times, .4ges use half
as much as .4gos, it's not eyeball apparent -- a screen paint is a
screen paint). Granted, we're talking mostly input programs and data
intensive reports where 'sqlturbo' gets more time than 'fglgo'.
The two big differences are load time and system resources.
With any large input program that several users run all day long, the
RDS version is extrememly expensive. For example:
500k .4gi program run by ten users.
With RDS, every user fires up fglgo, and that executable gets
automagically shared by UNIX. However, each one must now allocate
AT LEAST 500k of unshared data space to load in the .4gi, plus
whatever requirements the program itself has.
Now, compile that 500k .4gi into a 2 meg .4ge, and those ten users
get to share that 2 meg versus allocating the extra 5 meg. That's
a pretty significant savings.
Also, when they fire up fglgo, it must makes its pass through the .4gi
and set up its internal structures etc etc, and that makes load times
slow down. A .4ge will load lickety split, especially if it's already
loaded somewhere else.
On some systems, compiling can make a real difference. On one client,
compiling 2 major input programs moved their system from swap city to
overjoyed users. But for the programs that are run once a day or less,
(reports mostly), its usually not worth the diskspace.
Will
(uunet!la4gen!villy)