A better value for ^%ZOSF("SIZE")

Bug #616438 reported by bhaskar on 2010-08-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenVista/GT.M Integration

Bug Description

The current ^%ZOSF("SIZE") loads the routine source into the process heap space and keeps it there for the lifetime of the process. Although this is not a big deal if only a small number of routines are $Text()ed, if many routines are, or if some routines are large (I have seen individual routines - not in VistA - of 150,000 lines and more) space may be used unnecessarily. The attached file is an example of ^%ZOSF("SIZE") that is likely to be more space efficient, even though it may be marginally slower than the current implementation.

bhaskar (bhaskar) wrote :

Arrgh! Those who write code are doomed to improve it!!! And those who use GT.M are doomed to finding alternative (and even occasionally better) ways of doing things.

Here is a slightly simpler and more efficient setexample.m that uses $STACK() rather than ZSHOW:"S" into a local variable.

Also, someone pointed out to me that on some platforms, ls -l on some Linuxes may use multiple spaces, and consequently the use of $PIECE() to get the size is not that robust. So, I am attaching a new utility program _MPIECE.m (like $PIECE() but which treats multiple occurrences of the separator as a single occurrence).

I make no claim of copyright to sizeexample.m (i.e., please consider it to be an example of code in the public domain). As _MPIECE.m is intended to eventually go into a GT.M release, it has the standard FIS copyright for GT.M utility programs, and is provided here under the terms of the GNU Affero General Public License version 3 (http://www.gnu.org/licenses/agpl.txt).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers