Any insight would depend upon knowing precisely what the "slice and dice" consisted of and the specifics of the struct
There's overhead in a struct; the more fields etc in it the more overhead to keep track. Presuming you saved pieces as arrays to rebuild fields would be one way I'd see. And, save has some overhead itself that is also undoubtedly somewhat more for higher level data forms than simple arrays. That is counteracted by compression algorithms for at least arrays; I'd presume also effective for content of struct variables. So, there is no easy answer.
>> x=linspace(0,1,1001); % arbitrary double vector
>> whos x % memory footprint
Name Size Bytes Class Attributes
x 1x1001 8008 double
>> save x x
>> whos -file x % reflects in memory size in storage
Name Size Bytes Class Attributes
x 1x1001 8008 double
>> dx=dir('x.mat') % file size < half actual in memory
dx =
struct with fields:
name: 'x.mat'
folder: 'C:\Users\Duane\Documents\MATLAB\Work'
date: '18-Dec-2019 13:46:01'
bytes: 3515
isdir: 0
datenum: 7.377775736226852e+05
>>
>> clear s % let's compare struct to array
>> s.x=x; % same content
>> whos s
Name Size Bytes Class Attributes
s 1x1 8184 struct
>> save s s % as before, reflects memory but 8184-8008 = 176 bytes overhead
>>
>> whos -file s.mat
Name Size Bytes Class Attributes
s 1x1 8184 struct
>> ds=dir('s.mat') % memory on disk
ds =
struct with fields:
name: 's.mat'
folder: 'C:\Users\Duane\Documents\MATLAB\Work'
date: '18-Dec-2019 13:38:54'
bytes: 3542
isdir: 0
datenum: 7.377775686805556e+05
>> ds.bytes-dx.bytes % additional overhead of 27 bytes. Recaptured most of the 176 in fact
ans =
27
>> s.y=rand(size(s.x)); % let's add another field
>> whos s % exactly double in memory
Name Size Bytes Class Attributes
s 1x1 16368 struct
>> save s s % now save new struct w/ two fields...
>> ds2=dir('s.mat')
ds2 =
struct with fields:
name: 's.mat'
folder: 'C:\Users\Duane\Documents\MATLAB\Work'
date: '18-Dec-2019 13:42:18'
bytes: 11132
isdir: 0
datenum: 7.377775710416667e+05
>>
the last shows sizable jump to support the second field in the struct relative to one field--of course the randomized data would likely contribute to that as well in not compressing so effectively, but I didn't pursue that difference
