In the Mythical Man Month, Fred Brooks provides an example of how a developer 'wasted' a few bytes of storage in the OS/360 control program by putting in a routine to handle leap years. In his view this was not necessary since the operator could reset the date once every 4 years. In those days memory was very expensive, and one of the main ways of charging for the machine, so freeing up a few bytes to the application program was seen as a good thing.
We are now used to machines with many gigabytes of memory and so you may be wondering why this blog started with a post on reducing memory usage, especially since memory is cheap and developers are expensive.
Let me start by stating that I am not advocating spending a lot of precious time trying to save a few bytes. In our case, because of large group views, large number of called action blocks and reuse of code in shared libraries, some of our server load modules were requiring over 100Mb. If you then have 20 of these loaded by the TE, you are now using 2Gb.
Paging memory to disk or swapping load modules in and out of the TE has a performance impact, so our thinking is that if you can reduce the memory usage of the application, then you can keep more load modules loaded and/or give more memory to the DBMS, which will be able to benefit from it and hence improve performance.
A second point is that most of the techniques that we are using are highly automated. We have developed tools to search for and remove unused views, and report on imperfect view matching (optionally only for repeated calls or those involving group views). There is therefore a very low overhead in implementing these good practices.
You should however consider the cost/benefit case for any coding standards that you adopt, and spending a lot of time trying to save a few bytes (or even a few Mb) is unlikely to be justifiable.
2 comments:
I have a totally different question. If it doesn't fit here, ignore it please.
Apart from the obvious benefits of Xtrace (as stated in the documentation) do you know of any extra good points that I can use to prove that Xtrace will eventually save a project money, if bought in addition to the tooling avialable now (MF trace, CICS trace, DB2 log, web log, error log, etc.
Thanks,
A.
Hi A,
The main benefit of xTrace is saving the developer time when debugging their Gen code. The amount of time saved will depend on how much tracing is required, but we estimate that the break even point is between 30 and 60 minutes tracing per developer per month, or 2-3 minutes per day!
Without xTrace, tracing in batch or IMS is very tedious (no native Gen trace available) and in CICS the GUI interface and other features of xTrace make tracing more productive.
xTrace allows you to step through each line of code, inspect and change attribute values, set breakpoints so that you can skip to the point where you want to start tracing and much more. All of these features provide a very productive trace/debug environment and are a big improvement over the other trace alternatives that you mention.
Some of the new features of xTrace 2.2 make it feasible to generate your code by default with trace enabled because of the low runtime overhead when you are not actively tracing. The benefit of this is that you can immediately start a trace session when required without needing to re-generate the code with trace.
There is also a feature to enable a database rollback at the end of the trace session to preserve your starting point in the database, this avoiding the need to reset the database prior to the next test run.
If you need more information, please send me an e-mail.
Post a Comment