Re: Converting 4GL to Unix-C/SQL
Posted in 1993
> In article <1v4phjINNi7c@emory.mathcs.emory.edu>, > walt@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)