why symbolic variables always size 8 bytes?

Each time I want to know how big a symbolic formula or variable is, it always return 8 bytes. I have tracked this issue from Matlab 2016b until now (2018b) and anything change.

syms a b c d e
h = a*b*c*a*c*d*e+a*b+c+d*e-a
f(a,b,c,d,e) = a*b*c*a*c*d*e+a*b+c+d*e-a
whos a h f
  Name      Size            Bytes  Class     Attributes

    a         1x1                 8  sym                 
    f         1x1                 8  symfun              
    h         1x1                 8  sym

Do someone know why this happen and how to solve it?

Answer 1

[Walter Roberson]

Symbolic variables and functions have their value stored in a separate process, and the MATLAB level only stores a header and a reference into the other process.

[gonzalo Mier]

So... I cannot know how much space my variables weight?

[Walter Roberson]

The amount of memory allocated for symbolic variables gets to be tricky to define. There is a lot of internal sharing of nodes, but there could be optimization for small positive numbers. For example, 2+x^2 might share memory for the 2's or maybe it would "inline" them. It can rewrite expressions into equivalent forms to try to save memory.

-x-y+(x+y)^2

could get rewritten into

N1: #smallsymbol len=1, "x" 
N2: #smallsymbol len=1, "y" 
N3: #smallsymbol len=5, "_plus"
N4: #smallargsfunction, nops=2, @N3, @N1, @N2
N5: #smallpositive, 2
N6: #bigsymbol, len=6, "_powe" "r"
N7: #bigsymbol, len=7, "_umin" "us"
N8: #smallargsfunction, nops=1, @N7, @N4
N9: #smallargsfunction, nops=2, @N6, @N4, @N5
N10: #smallargsfunction, nops=2, @N3, @N8, @N9

... But half of those nodes probably existed already from when the basic libraries were loaded and those nodes would have been reused. If there is an existing node for the symbol _plus then is it fair to count the memory cost entirely against the new expression?

In the above, "small" and "big" has to do with efficiencies, that if you have a fixed-length node information slot then you can pack a limited amount of information into it right there, but if the information is too long to fit in that small space then you need to use additional memory.

The above is not intended to be what the MuPAD symbolic engine really uses internally: it is an approximate model of how data is represented in a different somewhat similar symbolic engine: lots and lots of tree structures that prefer to re-use existing nodes to save memory (it also has to do with efficiency.)