Re: Pseudo Code or Compiled

I sent this to Phil, and then Terry chimed in with the same question. So, I guess I'll flood the public mindeset with the whole durn thing. Is this in the FAQ? Enjoy! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Phil Mack, Sage of sages, spontaneously contributes: > > Could you shed a little light on this ? > > We have psuedo code running on a HP. The runner is shared in memory > but I believe I am right in saying that the code is loaded in each time > for each user and that is why the data element of the stack is so large. > > Is there a potential saving of memory if the code were compiled > and therefore shareable ? > > Will the system run that little bit faster ? > > I believe the answer to both these question is YES > > Any thoughts... You are pretty much correct. Here's the deal: UNIX loads and runs fglgo for the 1st user. Fglgo then loads the prog.4gi into its data segment, and proceeds to interpret it. The next user fires off 'fglgo prog.4gi'. UNIX sees that 'fglgo' is already loaded, and shares its text segment with the new user. However, it still must load a new copy of prog.4gi, because it is treated as pure data, and is therefore not shared. But, here's the rub. When you compile a .4gi file into a .4ge file, which is then a pure executable, a lot of the run time system is compiled with the code, so each .4ge is significantly larger than the .4gi. And many times, it is large the the combination of the 'fglgo' and the '.4gi'. (For example, fglgo may take .5 meg, and your .4gi may take 200k, but a compiled .4ge for the same program may take up 1.5 meg). This is changing a bit with shared libraries, but that is implementation dependant. What we have found is that for the large, central programs that are used by several people simultaneously (like the core Order Entry program or something similiar), there is a GREAT benefit in compiling the code because all of the users will be sharing the same code in the system. The system load is merely whatever data is unique to each program, but all of the executable is shared. One system we serviced had 10 users. Running fglgo on their main OE program, the system was just brought to its knees. Compiling the program brought new life into that system. Now for the programs that are run alone, or rarely, we've found there is no real need to compile the code, as they take less space uncompiled and there would be less shared among the users running these many one-shot programs. These programs include daily department reports, simple maintenance programs, etc. Anything that would only be used by one person at a time. As far as performance, compiled programs tend to load VERY quickly. The time between typing in 'prog.4ge' and getting a screen up is really snappy compared to 'fglgo prog.4gi'. Running a process and looking at the CPU time consumed, you'll find that compiled programs use about half as much time as p-code programs. However, one thing that we really haven't seen is any NOTICABLE difference in performance. Besides load time, seat of the pants performance checks do not show compile code to be much faster than p-code. Certainly not twice as fast. The reason here is that MOST of the time spent in our applications is in the backend. If you have a report that processes 1000 rows, and each row takes 10 seconds to get from the database, it really doesn't matter if your report processing take 3 minutes or 6 minutes when 2.5 hours are spent in the database. So, except for a few large, interactive programs, we have decided to not compile most of our code. It saves on disk space, doesn't affect performance significantly in our applications, and we've found that it tends to be safer as well. Plus we can use the debugger on client systems that have it installed. One BIG difference between compiled code and p-code is that in compiled code, variables are NOT initialized to 0 or NULL. This means that you can potentially have a process that works just GREAT in p-code, but does wierd, explosive things when compiled. Most development is done in p-code because of the turn around times and the debugger, so little bits like uninitialized variables can slip out and not rear their ugly heads until you compile the code, and then it can become VERY intermittent (always my favorite kind of bug to track down -- "Works great in the debugger!!!" :-)). I imagine if you have a large system, with a lot of people, then compiling everything will lower the overall load on the system, all of the time. But, most of the systems we have worked on are not that close to the edge of performance, or loaded enough where compiling everything would be a significant difference. One or two core programs, yes, but not everything. Hope that gives you the insight you need. Good Luck, Will Hartung (villy@collinscomp.com)