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

[Arne Vajhøj]

On 6/2/2021 5:02 PM, Craig A. Berry wrote:
> 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.

That makes sense.


>> 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.

If you need you application to be both standalone and embeddable
then that is what you have to do.

I don't know how common it it.

>>>                   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.

Yep.

>> 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.

Considering all the stuff that happens today then dynamic image
loading is probably not so bad. It must be way way less
overhead than a JIT compiler.

Arne