Length of variable names and execution speed

[augustk]

I have a very vague idea of what Dyalog APL does when a function is fixed (established) in the workspace. I imagine that it is translated into an internal representation which can be efficiently interpreted. More specifically, are variable names kept intact or are they translated to something shorter for efficient retrieval; in other words can the length of variable names affect the execution speed?

On a side note I lost my first post after my login timed out and I pressed Submit. Not very nice.

[Veli-Matti]

Hi,
as far as I know, the variable lengths are no big deal. If I remember it right, the Dyalog guys talk something about using internal tokens here..
For example, let's create following variables with diferent name lengths(in v.18):

      a←1e6(?⍴)0 ⋄ b←1e6(?⍴)0
      ⍎(1e3/'a'),'←a' ⋄ ⍎(1e3/'b'),'←b'
      ⍎(1e6/'a'),'←a' ⋄ ⍎(1e6/'b'),'←b'
      (a+b)≡⍎(1e6/'a'),'+',1e6/'b'
1

...and make three stup..simple functions:

      ⎕fx'z←foo' 'z←a+b'
      ⎕fx'z←goo' ('z←',(1e3/'a'),'+',1e3/'b')
      ⎕fx'z←hoo' ('z←',(1e6/'a'),'+',1e6/'b')

Speed testing them against each other gives no visible difference

      ]runtime -c "foo" "goo" "hoo"
                                                              
  foo → 2.2E¯3 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕ 
  goo → 2.2E¯3 | -1% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕ 
  hoo → 2.3E¯3 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

Of course, executing takes a tad longer:

      ]runtime -c "⍎'a+b'" "⍎(1e6/'a'),'+',1e6/'b'"
                                                                                   
  ⍎'a+b'                 → 2.2E¯3 |    0% ⎕⎕⎕⎕⎕⎕                                   
  ⍎(1e6/'a'),'+',1e6/'b' → 1.5E¯2 | +591% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

But I assume that in normal cases the variable name lengths do not matter.
-Veli-Matti

[Vince|Dyalog]

Hi AugustK,

When the function is fixed, the APL source is turned into numerical tokens. The names will be indices into a symbol table. The length of the names will not cause a problem or slow performance unless you are using execute like Veli-Matti pointed out.

Regards,

Vince

[augustk]

Thanks for the clarification, Vince.

[AndyS|Dyalog]

Several years ago we found a number of bugs due to exceedingly long names, so we prevented a number of those bugs by simply limiting the length of a name to something like ¯1+2*31. Mind you, once you get to 2*10 or so I think you'll find that you'll hit problems with ⎕NR etc.

Once you've got your function compiled, then as Veli-Matti and Vince state, the length of a name won't impact the performance of the function. But the longer a name, the longer it will take to open the editor, or generate the output of )si etc etc. And the autocomplete dropdown might take some time to open !

And of course the name has to be held in the workspace .. so the longer the names, the less space there is for other stuff.