Re: large .4ge ~ Answered: amber (solid confidence) — Message quotes the full original question about splitting a large .4ge into smaller modules and gives a detailed, first-hand answer covering memory sharing, RUN vs CALL trade-offs, and a shared-object build trick; not confirmed by the asker.

Advisory only.

Noel O'Brien (noel@paragon.ie) wrote: : Does anybody know if Performance can be slower by using one : .4ge instead of a .4ge for each program ? : I have a .4ge about 4meg which could be split into possibly : 30 .4ge's . Is it better to 'RUN something.4ge' from within : another .4ge or stay with the 1 .4ge and just 'CALL somefunction' ? I've wondered this myself. My .4ge is approaching 5MB. There doesn't seem to be any performance penalty as long as I have the system resources to load and execute without swapping. Multiple users of the same program can share the text portions, so the overall memory consumption is not too bad. Even the program load time is suprisingly brief, probably due to the demand-loading feature of the paging architecture. On the other hand, there are considerable disadvantages to breaking up the .4ge into smaller programs. The 4GL RUN statement makes it difficult to return data from a child process. The screen flash and delay while invoking a child process is undesirable. Moreover, parent and child cannot share a database transaction, nor access rows locked by the other. The biggest drawback has been the time required for relinking the application--it is now taking more than 2 minutes. But I have found a way to circumvent this is my development environment--building shared objects. By linking my largest .o files into .so shareable objects, and then linking these to my application, I have reduced my development time and also the size of the resulting .4ge considerably. But I am still linking a static .4ge for production. -- Jeff Sturm ZenaComp Incorporated jsturm@zenacomp.com