Hermann Tegermann · May 17, 2022

What's better: Local Variable Arrays or Process Private Globals

In various tests I used both and found no real reason to prefer the one or the other.
Eventually I missed some limits. At least I didn't hit any.
What is the general opinion?
Where to use the one or the other?

0 601
Discussion (11)5
Log in or sign up to continue

Hi !

In my experience, if you process a lot of nodes into your array, is better "Process Private Globals", because it can use disk resource after complete all the RAM resource asigned to the particular process, like a normal global. In the case of  "Local Variable Arrays" you only use RAM.

If you don't need many nodes and your nodes save a small data, is better "Local Arrays". But if you have a lot of nodes and each one save large data (like xml content or csv file ) is better  "Process Private Globals".

Best Regards.

OK !
They look rather similar.


  • Process Private Globals are "unlimited". 
    Clear there is a physical limit, but it's far away compared to local variables.
  • PPGs are best suited as Storage location + Index location of temporary tables.
    Without limit as any ordinary Global. 

So it depends on your needs.

Bear in mind that local variable arrays can hold orefs but PPGs cannot:

Cache for Windows (x86-32) 2017.2.2 (Build 865U) Mon Jun 25 2018 11:10:00 EDT
SAMPLES>s oP=##class(Sample.Person).%OpenId(1)
Gallant,Yan N.
SAMPLES>s LocalArray(1)=oP
SAMPLES>s ^||PPG(1)=oP
SAMPLES>w LocalArray(1).Name
Gallant,Yan N.
SAMPLES>w ^||PPG(1).Name
W ^||PPG(1).Name
SAMPLES>w $isobject(^||PPG(1))
SAMPLES>w LocalArray(1)
SAMPLES>w $isobject(LocalArray(1))

And if so?

w $zobjref(^||PPG(1)).Name

Still take a look at $$$objOrefToInt/$$$objIntToOref (%occObject.inc)

PS: it should be noted that OREF ≠ OID and serve different purposes.

That would work only in the cases where original reference to OREF exists, right?

In particular,  an object is garbage collected when there are no ways to access that object using oref values starting from an oref-type value stored in a local variable.  When an oref is converted to an integer (or to a string) then that does not count as an object reference.  Store that integer/string in a PPG and then do KILLs (or otherwise make changes) of oref-type values referring to an object then that object will be deleted despite the fact a PPG (or any other variable) contains an integer/string reference to the object.

Excellent & valid comment !
I didn't think of this difference before.

Hi, I'm very new to the world of InterSystems, I'm an intern at a hospital who has taken 1.5 years of CS classes. I could be misunderstanding but this seems like a 'local variable vs global variable' argument specific to InterSystems. In my classes I have always been told to stay away from global variables and to use local variables. They say it keeps the program from getting to intertwined/ tightly coupled, and makes it easier to keep your data from being modified when you don't want it to be. It supposedly makes the code easier for everyone to understand and easier to fix bugs. I found it interesting that no one mentioned this when it is mentioned a lot in school. Is this something students are told early on in their education to practice good coding or is it just not a concern in this case?

This is a rather common misunderstanding.
The naming GLOBAL was created in the 60ties.
Long before any other programming language even had anything named Global or similar.

GLOBAL in Caché is a persistent storage component that builds the backbone of (SQL) Tables and Persistent Objects.

see this documentation: Using Caché Globals