file - MATLAB:将多个变量保存到 "-v7.3"(HDF5) .mat 文件在使用 "-append"标志时似乎更快。怎么来的？

Question

注意: 此问题涉及 2011 年使用旧 MATLAB 版本 (R2009a) 观察到的问题。根据以下 2016 年 7 月的更新，MATLAB 中的问题/错误似乎不再存在(使用 R2016a 测试；向下滚动到问题末尾以查看更新)。

我正在使用 MATLAB R2009b，我需要编写一个更大的脚本，将更大的 .zip 文件集的内容转换为 v7.3 mat 文件(具有底层 HDF5 数据模型)。阅读没问题。问题在于储蓄。而且实际上没有问题。我的文件使用 save 命令保存得很好。

我的问题更多是在某种意义上:为什么我会在 MATLAB 中观察到以下令人惊讶的(对我而言)行为？

让我们来看看我的问题。在当前的测试场景中，我将生成一个输出:-v7.3 mat-file。这个 .mat 文件将包含 40 个块作为单独的变量。每个变量将被命名为“block_NNN”，从 1 到 40，并将包含一个带有字段 frame 和 blockNo 的结构。场帧包含一个 480x240x65 的 uint8 图像数据序列(这里只是使用 randi 生成的随机数据)。字段 blockNo 包含块编号。

备注:在真正的脚本中(我还没有完成)，我将执行上述总共 370 次，转换总共 108GB 的​​原始数据。这就是为什么我关心以下问题。

无论如何，首先我定义一些通用变量:

% 虚拟数据和循环的一些大小:
num_blockCount = 40;
num_blockLength = 65;
num_frameHeight = 480;
num_frameWidth = 240;

然后我生成一些形状和大小与实际原始数据相同的虚拟代码:

% 生成空结构:
stu_data2disk = struct();

% 循环块:
对于 num_k = 1:num_blockCount

% 生成块名:
temp_str_blockName = sprintf('block_%03u', num_k);

% 为当前块生成临时结构:
temp_stu_value = struct();
temp_stu_value.frames = randi( ...
[0 255], ...
[num_frameHeight num_frameWidth num_blockLength], ...
'uint8' ...
);
temp_stu_value.blockNo = num_k;

% 使用动态字段名称:
stu_data2disk.(sprintf('block_%03u', num_k)) = temp_stu_value;

结尾

我现在所有的随机测试数据都在 struct stu_data2disk 中。现在我想使用两种可能的方法之一保存数据。

让我们先试试简单的:

% 保存数据(简单):
disp('以简单的方式保存数据:')
抽动;
保存已转换的.mat -struct stu_data2disk -v7.3;
托克;

该文件写入没有问题(286MB)。输出是:

以简单的方式保存数据:
耗时是 14.004449 秒。

好的 - 然后我记得我想在 40 个块上遵循保存过程。因此，我循环遍历块并按顺序附加它们，而不是上面的:

% 保存到文件，使用附加:
disp('使用-append保存数据:')
抽动;
对于 num_k = 1:num_blockCount

% 生成块名:
temp_str_blockName = sprintf('block_%03u', num_k);

temp_str_appendToggle = '';
如果 (num_k > 1)
temp_str_appendToggle = '-append';
结尾

% 生成保存命令:
temp_str_saveCommand = [ ...
'节省 '， ...
'converted_append.mat', ...
'-struct stu_data2disk'、temp_str_blockName、''...
temp_str_appendToggle, ' ', ...
'-v7.3', ...
';' ...
];

% 评估保存命令:
评估(temp_str_saveCommand)；

结尾
托克;

该文件再次保存得很好(286MB)。输出是:

使用 -append 保存数据:
耗时是 0.956968 秒。

有趣的是，附加方法要快得多？ 我的问题是为什么？

从 dir converted*.mat 输出:

09-02-2011 20:38 300,236,392 转换.mat
09-02-2011 20:37 300,264,316converted_append.mat
2 个文件 600,500,708 字节

这些文件的大小不同。在 Windows 7 中使用 fc 进行的测试揭示了......很多二进制差异。也许数据被移动了一点 - 因此这没有告诉我们什么。

有人知道这里发生了什么吗？附加文件是否使用了更优化的数据结构？或者，也许 Windows 已经缓存了该文件并使其访问速度更快？

我也努力从这两个文件中试读。如果没有在此处显示数字，附加版本会快一点(尽管从长远来看可能意味着什么)。

[编辑] :我只是尝试不使用格式标志(在我的系统上默认为 -v7)并且没有太大区别了:

以简单的方式保存数据 (-v7):
耗时是 13.092084 秒。
使用 -append (-v7) 保存数据:
耗时是 14.345314 秒。

[编辑] :我更正了上述错误。之前我提到过统计数据是针对 -v6 的，但我错了。我刚刚删除了格式标志并假设默认值为 -v6 但实际上它是 -v7。

我使用 Andrew 的精细框架为系统上的所有格式创建了新的测试统计数据(所有格式都用于相同的随机测试数据，现在从文件中读取):

15:15:51.422:在 PCWIN 上测试速度，格式=-v6，R2009b，arch=x86，os=Microsoft Windows 7 Professional 6.1.7600 N/A Build 7600
15:16:00.829:保存简单的方法:0.358 秒
15:16:01.188:使用多个附加保存:7.432 秒
15:16:08.614:使用一个大追加保存:1.161 秒

15:16:24.659:在 PCWIN 上测试速度，格式=-v7，R2009b，arch=x86，os=Microsoft Windows 7 Professional 6.1.7600 N/A Build 7600
15:16:33.442:保存简单的方法:12.884 秒
15:16:46.329:使用多个附加保存:14.442 秒
15:17:00.775:使用一个大追加保存:13.390 秒

15:17:31.579:测试速度，格式=-v7.3，PCWIN 上的 R2009b，arch=x86，os=Microsoft Windows 7 Professional 6.1.7600 N/A Build 7600
15:17:40.690:保存简单的方法:13.751 秒
15:17:54.434:使用多个附加保存:3.970 秒
15:17:58.412:使用一个大追加保存:6.138 秒

以及文件的大小:

10-02-2011 15:16 299,528,768 转换格式-v6.mat
10-02-2011 15:16 299,528,768converted_append_format-v6.mat
10-02-2011 15:16 299,528,832 Converted_append_batch_format-v6.mat
10-02-2011 15:16 299,894,027 转换格式-v7.mat
10-02-2011 15:17 299,894,027converted_append_format-v7.mat
10-02-2011 15:17 299,894,075converted_append_batch_format-v7.mat
10-02-2011 15:17 300,236,392 转换格式-v7.3.mat
10-02-2011 15:17 300,264,316 Converted_append_format-v7.3.mat
10-02-2011 15:18 300101800converted_append_batch_format-v7.3.mat
9 个文件 2,698,871,005 字节

因此 -v6 似乎是最快的写入。文件大小也没有任何大的差异。据我所知，HDF5 确实内置了一些基本的膨胀方法。

嗯，可能是在底层 HDF5 写入函数中进行了一些优化？

目前我仍然认为一些底层的基本 HDF5 写入函数已针对将数据集添加到 HDF5 文件进行了优化(这是在将新变量添加到 -7.3 文件时发生的情况)。我相信我在某处读到过 HDF5 应该以这种方式进行优化......虽然不能确定。

其他需要注意的细节:

正如我们在下面安德鲁的回答中看到的那样，这种行为是非常系统的。是否在函数的局部范围内或在 m 脚本的“全局”范围内运行这些东西似乎也很重要。我的第一个结果来自一个 m 脚本，其中文件被写入当前目录。我仍然只能在 m 脚本中重现 -7.3 的 1 秒写入。函数调用显然会增加一些开销。

2016 年 7 月更新 :

我再次发现了这个，并认为我可以使用目前可用的最新 MATLAB 对其进行测试。在 Windows 7 x64 上使用 MATLAB R2016a 问题似乎已得到解决:

14:04:06.277:测试速度，imax=255，PCWIN64 上的 R2016a，arch=AMD64，16 GB，os=Microsoft Windows 7 Enterprise Version 6.1(Build 7601:Service Pack 1)
14:04:10.600:基本 -v7.3:7.599 秒 5.261 GB 使用
14:04:18.229:基本 -v7.3:7.894 秒 5.383 GB 使用
14:04:26.154:基本 -v7.3:7.909 秒 5.457 GB 使用
14:04:34.096:基本 -v7.3:7.919 秒 5.498 GB 使用
14:04:42.048:基本 -v7.3:7.886 秒 5.516 GB 使用 286 MB 文件 7.841 秒平均值
14:04:50.581: multiappend -v7.3: 7.928 sec 5.819 GB 使用
14:04:58.544: multiappend -v7.3: 7.905 sec 5.834 GB 使用
14:05:06.485:multiappend -v7.3:8.013 秒 5.844 GB 使用
14:05:14.542: multiappend -v7.3: 8.591 sec 5.860 GB 使用
14:05:23.168:multiappend -v7.3:8.059 秒 5.868 GB 使用 286 MB 文件 8.099 秒平均
14:05:31.913:bigappend -v7.3:7.727 秒 5.837 GB 使用
14:05:39.676: bigappend -v7.3: 7.740 sec 5.879 GB 使用
14:05:47.453:bigappend -v7.3:7.645 秒 5.884 GB 使用
14:05:55.133:bigappend -v7.3:7.656 秒 5.877 GB 使用
14:06:02.824:bigappend -v7.3:7.963 秒 5.871 GB 使用 286 MB 文件 7.746 秒平均值

这是在下面接受的答案中使用 Andrew Janke 的 reproMatfileAppendSpeedup 函数进行了测试(5 次通过，格式为 7.3)。现在， -append 对于单次保存同样缓慢或更慢 - 应该如此。也许这是 R2009a 中使用的 HDF5 驱动程序的早期构建的问题。

Answer 1

天啊。我可以繁殖。也尝试了单追加变体；它甚至更快。看起来“-append”只是神奇地使基于 HDF5 的 save() 速度提高了 30 倍。我没有解释，但我想分享我的发现。

我将您的测试代码封装在一个函数中，对其进行重构以使保存逻辑与测试数据结构无关，以便您可以在其他数据集上运行它，并添加了更多诊断输出。

不要到处都看到大的加速。它在我的 64 位 XP 机器和 32 位 Server 2003 机器上很大，在我的 64 位 Windows 7 机器上很大，在 32 位 XP 机器上不存在。 (尽管在 Server 2003 上多次追加是一个巨大的损失。)在许多情况下，R2010b 速度较慢。也许 HDF5 附加或保存对它的使用只是在较新的 Windows 版本上摇滚。 (XP x64 实际上是 Server 2003 内核。)或者这只是机器配置的差异。 XP x64 机器上有一个快速 RAID，而 32 位 XP 的 RAM 比其他机器少。您正在运行什么操作系统和架构？你也可以试试这个repro吗？

19:36:40.289: Testing speed, format=-v7.3, R2009b on PCWIN64, arch=AMD64, os=Microsoft(R) Windows(R) XP Professional x64 Edition 5.2.3790 Service Pack 2 Build 3790
19:36:55.930: Save the simple way:           11.493 sec
19:37:07.415: Save using multiple append:     1.594 sec
19:37:09.009: Save using one big append:      0.424 sec


19:39:21.681: Testing speed, format=-v7.3, R2009b on PCWIN, arch=x86, os=Microsoft Windows XP Professional 5.1.2600 Service Pack 3 Build 2600
19:39:37.493: Save the simple way:           10.881 sec
19:39:48.368: Save using multiple append:    10.187 sec
19:39:58.556: Save using one big append:     11.956 sec


19:44:33.410: Testing speed, format=-v7.3, R2009b on PCWIN64, arch=AMD64, os=Microsoft Windows 7 Professional  6.1.7600 N/A Build 7600
19:44:50.789: Save the simple way:           14.354 sec
19:45:05.156: Save using multiple append:     6.321 sec
19:45:11.474: Save using one big append:      2.143 sec


20:03:37.907: Testing speed, format=-v7.3, R2009b on PCWIN, arch=x86, os=Microsoft(R) Windows(R) Server 2003, Enterprise Edition 5.2.3790 Service Pack 2 Build 3790
20:03:58.532: Save the simple way:           19.730 sec
20:04:18.252: Save using multiple append:    77.897 sec
20:05:36.160: Save using one big append:      0.630 sec

这看起来很大。如果它适用于其他数据集，我自己可能会在很多地方使用这个技巧。这也可能是 MathWorks 提出的问题。他们是否也可以在正常保存或其他操作系统版本中使用快速追加技术？

这是自包含的重现功能。

function out = reproMatfileAppendSpeedup(nPasses, tests, imax, formats)
%REPROMATFILEAPPENDSPEEDUP Show how -append makes v7.3 saves much faster
%
% Examples:
% reproMatfileAppendSpeedup()
% reproMatfileAppendSpeedup(2, [], 0, {'7.3','7','6'}); % low-entropy test

if nargin < 1 || isempty(nPasses);  nPasses = 1;  end
if nargin < 2 || isempty(tests);    tests = {'basic','multiappend','bigappend'}; end
if nargin < 3 || isempty(imax);     imax = 255; end
if nargin < 4 || isempty(formats);  formats = '7.3'; end % -v7 and -v6 do not show the speedup
tests = cellstr(tests);
formats = cellstr(formats);

fprintf('%s: Testing speed, imax=%d, R%s on %s\n',...
    timestamp, imax, version('-release'), systemDescription());

tempDir = setupTempDir();
testData = generateTestData(imax);

testMap = struct('basic','saveSimple', 'multiappend','saveMultiAppend', 'bigappend','saveBigAppend');

for iFormat = 1:numel(formats)
    format = formats{iFormat};
    formatFlag = ['-v' format];
    %fprintf('%s: Format %s\n', timestamp, formatFlag);
    for iTest = 1:numel(tests)
        testName = tests{iTest};
        saveFcn = testMap.(testName);
        te = NaN(1, nPasses);
        for iPass = 1:nPasses
            fprintf('%s: %-30s', timestamp, [testName ' ' formatFlag ':']);
            t0 = tic;
            matFile = fullfile(tempDir, sprintf('converted-%s-%s-%d.mat', testName, format, i));
            feval(saveFcn, matFile, testData, formatFlag);
            te(iPass) = toc(t0);
            if iPass == nPasses
                fprintf('%7.3f sec      %5.3f GB used   %5.0f MB file   %5.3f sec mean\n',...
                    te(iPass), physicalMemoryUsed/(2^30), getfield(dir(matFile),'bytes')/(2^20), mean(te));
            else
                fprintf('%7.3f sec      %5.3f GB used\n', te(iPass), physicalMemoryUsed/(2^30));
            end
        end
        % Verify data to make sure we are sane
        gotBack = load(matFile);
        gotBack = rmfield(gotBack, intersect({'dummy'}, fieldnames(gotBack)));
        if ~isequal(gotBack, testData)
            fprintf('ERROR: Loaded data differs from original for %s %s\n', formatFlag, testName);
        end
    end
end

% Clean up
rmdir(tempDir, 's');

%%
function saveSimple(file, data, formatFlag)
save(file, '-struct', 'data', formatFlag);

%%
function out = physicalMemoryUsed()
if ~ispc
    out = NaN;
    return; % memory() only works on Windows
end
[u,s] = memory();
out = s.PhysicalMemory.Total - s.PhysicalMemory.Available;

%%
function saveBigAppend(file, data, formatFlag)
dummy = 0;
save(file, 'dummy', formatFlag);
fieldNames = fieldnames(data);
save(file, '-struct', 'data', fieldNames{:}, '-append', formatFlag);

%%
function saveMultiAppend(file, data, formatFlag)
fieldNames = fieldnames(data);
for i = 1:numel(fieldNames)
    if (i > 1); appendFlag = '-append'; else; appendFlag = ''; end
    save(file, '-struct', 'data', fieldNames{i}, appendFlag, formatFlag);
end


%%
function testData = generateTestData(imax)
nBlocks = 40;
blockSize = [65 480 240];
for i = 1:nBlocks
    testData.(sprintf('block_%03u', i)) = struct('blockNo',i,...
        'frames', randi([0 imax], blockSize, 'uint8'));
end

%%
function out = timestamp()
%TIMESTAMP Showing timestamps to make sure it is not a tic/toc problem
out = datestr(now, 'HH:MM:SS.FFF');

%%
function out = systemDescription()
if ispc
    platform = [system_dependent('getos'),' ',system_dependent('getwinsys')];
elseif ismac
    [fail, input] = unix('sw_vers');
    if ~fail
        platform = strrep(input, 'ProductName:', '');
        platform = strrep(platform, sprintf('\t'), '');
        platform = strrep(platform, sprintf('\n'), ' ');
        platform = strrep(platform, 'ProductVersion:', ' Version: ');
        platform = strrep(platform, 'BuildVersion:', 'Build: ');
    else
        platform = system_dependent('getos');
    end
else
    platform = system_dependent('getos');
end
arch = getenv('PROCESSOR_ARCHITEW6432');
if isempty(arch)
    arch = getenv('PROCESSOR_ARCHITECTURE');
end
try
    [~,sysMem] = memory();
catch
    sysMem.PhysicalMemory.Total = NaN;
end
out = sprintf('%s, arch=%s, %.0f GB, os=%s',...
    computer, arch, sysMem.PhysicalMemory.Total/(2^30), platform);

%%
function out = setupTempDir()
out = fullfile(tempdir, sprintf('%s - %s', mfilename, datestr(now, 'yyyymmdd-HHMMSS-FFF')));
mkdir(out);

编辑:我修改了 repro 函数，添加了多次迭代并将其参数化以用于兰迪生成器的保存样式、文件格式和 imax。

我认为文件系统缓存是快速追加行为的一个重要因素。当我使用 reproMatfileAppendSpeedup(20) 连续运行大量程序并在 Process Explorer 中查看系统信息时，其中大部分时间不到一秒，并且物理内存使用量迅速增加了几 GB。然后每经过 12 次，写入就会停止并需要 20 或 30 秒，物理 RAM 使用量会慢慢下降到开始的位置。我认为这意味着 Windows 在 RAM 中缓存了大量写入，并且有关 -append 的某些内容使其更愿意这样做。但对我来说，包括那些摊位在内的摊销时间仍然比基本保存快很多。

顺便说一句，在进行了几个小时的多次传递后，我很难重现原始时间。