Re: R4GL V C4GL

> > In article <33jh1i$n93$2@heifetz.msen.com> jsturm@garnet.msen.com (Jeffrey Sturm) writes: > >*.4gi's are *much* smaller than *.4ge's and system memory usage > >is sometimes reduced because typically many fglgo processes run at once > >and Unix can share the .text segments. In contrast, C4GL compiles the > >runtime (equivalent of fglgo) into every .4ge produced, wasting > >disk and VM. > > Except that with a demand paged Unix a 4ge will typically (ie average > case) use less real memory than fglgo, since fglgo reads the whole 4gi > pcode program before running. ie the 4ge starts off with a minimally > small active page set, while the fglgo starts off with a maximally > large set. Of course in the worst case the 4ge can end up using much > more memory, but this is not so common in practise. The best part about the RDS vs C4GL is that situations like memory usage become tunable. If you're running one or the other, you don't get a choice. The advantages of RDS is that the programs tend to be smaller, so if you are running several DIFFERENT programs simultaneously, you get the benefit of the smaller core size. However, if you have several people running the SAME program simultaneously, then RDS quickly becomes a limitation and a can in turn be a real pig. Where the trade off occurs is how much of the image that the UNIX system can share across users. Running RDS, only 'fglgo' can be shared, whereas running a .4ge, most of the application can be shared. Let's take a large maintenance program for an example. Let's say that the .4gi of this program is 1MB, fglgo takes .5mb and the .4ge take 2.5MB. (The .4ge can vary widely, especially on the RISC boxes). We'll assume that the 4gi and 4ge are the same program, and whatever local dataspace is required by the program (global variables) is washed from our equation, since they'll be the same. if three people run the 4gi, then you've got in memory: o 1 copy of 'fglgo' being shared among the users. o 3 copys of x.4gi, one for each user. for a cost of roughly 3.5MB or memory. Now, if three people are running x.4ge, you really only have one copy in memory, with the .text of the entire app being shared, for a cost of 2.5MB (the size of the .4ge). However, if you have 3 people running 3 DIFFERENT programs (all being the size above), then with RDS you have a total memory being consumed of 3.5 (like before), but the .4ges suck up 7.5, because they are all unique routines (yes, shared libraries will affect this, but you get the idea). So, what happens in a lot of systems, is that there are several people doing data entry with one or two programs that they live in most of the day, whereas the back office folks are running random reports and maintenance routines with little regularity. What seems to work out best is to use C4GL on the large data entry programs that are used by several people, and leave the rest with RDS, since they won't benefit from the sharing. We had an R/S 6000 that went from swap hell to sing-song performance by compiling one program, in a system of over a hundred programs. Now, none of this is black and white, cut and dried, but it does seem to be an effective process in balancing system resources, and seems to generally work. > >The biggest drawback of R4GL I've witnessed is slow program load times > >because of runtime binding. I've always wondered if Informix would ever > >implement a *real* linker/librarian (like ld/ar) for RDS instead of just > >/bin/cat ... > > Yep. We certainly make extensive use of both archive and dynamic > shared libraries, so RDS is of limited use to us. Which is a shame, > really. Yeah, .4ges just snap right to it whereas a .4gi can just suck as it loads everything up. Also, if you just look at system timings, RDS seem to run about 70% slower than a similiar .4ge, although from a user point of view its hardly noticable for most programs. Also, Informix Forms/Fourgen has a facility that fakes library management pretty well for RDS stuff. Will (villy@collinscomp.com)