[Info-vax] How much of VMS is still in MACRO-32?

[Craig A. Berry]

On 6/2/21 8:08 AM, Arne Vajhøj wrote:
> On 6/1/2021 9:34 PM, Craig A. Berry wrote:
>> On 6/1/21 12:33 PM, Stephen Hoffman wrote:
>>> On 2021-06-01 15:27:34 +0000, Marc Van Dyck said:
>>>> Don't you do that with Source Code Analyzer, for languages that 
>>>> support it ?
>>
>>> I use DECset SCA and PCA only  rarely, as few sites have licenses for
>>> that. Which means using symbol tables and maps, and the debugger,
>>> and  preferably refactoring where permitted.
>>
>> And as far as I remember PCA doesn't work on shareable images, which
>> means on any kind of application with a semi-modern architecture, you
>> either do without
> 
> Would it ignore the time spent in the shareable image or would it just
> count it as being spent in the calling code?

IIRC, it counts it all as being in the calling code.

> The latter may be good enough for many purposes.

Not when you have a tiny bootstrap program that loads a library to do
all the heavy lifting -- then it tells you that 99.9999% of the time was
taken by the one routine that loads the library. I believe this is a
fairly common architecture; it's certainly one way to make a package
that can be run standalone but also be embedded in other programs.


>>                   or you mangle your build procedures to make a static
>> version, which in turn makes the results of any performance analysis
>> somewhat suspect for drawing conclusions about the real-world 
>> application.
> 
> It would be a hassle. And if it is external code then one may not even
> be able to do it.

And if things get loaded via LIB$FIS then you're going to have to change
program logic as well as build procedures to try to make a static image
that has everything that normally resides in potentially dozens or
hundreds of shareable images.


> But why do you expect a big difference in result due to static
> linking?

Possibly it wouldn't be today.  I guess I had in mind that old post
about "A Day in the Life of the Image Activator."  There is also the
chance that you'll run out of memory or pagefile, again less likely
today than yesteryear, but still possible.