The 112 I think is an estimate of the size of an mxArray header (the internal structure for each variable that MATLAB uses behind the scenes to store type, size, data pointers, etc.). Each variable in a struct could have a unique one. In the header hacks I use in my mex routines I get a different number, either 96 or 88 for 64-bit MATLAB depending on the version. But this number is uncertain outside of TMW since they stopped publishing this in their distributed mex headers several years ago. The actual storage could be less if some of the variables are shared reference copies of other variables (i.e., sharing the mxArray header).
The 64 I think is a max value for the string used to store a field name (63 for the string itself and 1 for the null character at the end of a C-style string). The field names could be less than that, of course, and they can also be sharing names with other variables.
The data memory can also be shared with other struct variables. Also realize that data will not in reality be allocated on single byte boundaries behind the scenes. And sparse matrix storage can be allocated to be more than the actual data present. Etc. So there is some fuzziness in those data numbers.
Bottom line is the formula should be viewed as approximate, and as a max storage footprint if nothing in the struct is shared with other variables. If I were to guess at such a formula, I might use this instead for 64-bit MATLAB:
(number of fields) * ( 8 * (number of struct array elements) + 64) +
(1 + number of non-NULL elements in the struct) * (96 or 88) +
(total amount of data storage for the elements)
The 8 is the storage needed for the pointers to the struct array elements. 96 would be used for R2017b and earlier, and 88 would be used for R2018a and later (TMW got rid of the seperate Pi complex data pointer when they went to interleaved complex).
