序幕
此答案基于作者在最近一周提供的原始帖子和澄清（两者）。
不良性能问题由一个低级的、依赖物理媒体的、“碎片化”引入，由文件系统和文件访问层引入 在 TimeDOMAIN 量级和 ComputingDOMAIN 重复性方面进一步面临这些这种方法的实际使用问题 .
最后提出了一种最先进的、主要是最快可能解决给定任务的解决方案，以最大程度地减少浪费的努力和误解造成的损失来自理想化或其他无效的假设，例如由于假设整个文件将在一个会话中写入（这基本上不可能在当代 O/S 的许多多核/多进程操作在创建时间和对 TB 大小的 BLOB 文件的一系列广泛修改（参考 MATLAB 大小限制）上实时进行-当代COTS文件系统中的对象）。
人们可能讨厌事实，但事实仍然存在，直到出现更快更好的方法
首先，在考虑性能之前，先意识到概念上的差距
真正的性能不利影响不是由 HDD-IO 引起的或与文件碎片有关
RAM 不是替代方法用于 .mat 文件的半永久存储
- 额外的操作系统限制和干预 + 额外的驱动程序和基于硬件的抽象在不可避免的开销假设中被忽略了
- 在对结果性能产生最大影响/影响的审查中省略了上述计算方案
鉴于：
整个处理旨在只运行一次，没有优化/迭代，没有连续处理
数据有 1E6 double 浮点值 x 1E5 列 = 关于 @987654327 @（+HDF5 开销）
尽管有原始帖子，但没有与处理相关的随机 IO
-
数据获取阶段与 .NET 通信以接收DataELEMENTs 进入 MATLAB
这意味着，从 v7.4 开始，
1.6 GB limit 在 32 位 Win 中的 MATLAB WorkSpace（2.7 GB，带 3GB 开关）
a 1.1 GB limit on MATLAB最大矩阵 in wXP / 1.4 GB wV / 1.5 GB
在 MATLAB WorkSpace 上有点“发布”2.6 GB limit + 32 位 Linux O/S 中最大矩阵的 2.3 GB 限制。
拥有 64 位操作系统不会帮助任何类型的 32 位 MATLAB 7.4 实现，并且由于另一个限制而无法工作，即数组中的最大单元数，这不会涵盖此处请求 1E12。
唯一的机会是同时拥有
数据存储阶段假设将按行排序的数据块（按行排序的数据块的集合）写入 HDD 设备上的MAT-file
数据处理阶段假定在获取所有输入并将其编组到基于文件的非 RAM 之后，在 HDD 设备上重新处理 MAT-file 中的数据- 存储，但以列顺序的方式
只需要按列计算mean()-s / max()-es（没有更复杂的）
事实：
- MATLAB 对二进制文件使用
HDF5 文件结构的“受限”实现。
Review performance measurements on real-data & real-hardware ( HDD + SSD ) to get feeling of scales of the un-avoidable weaknesses thereof
分层数据格式 (HDF) 于大约 20 年前于 1987 年在国家超级计算应用中心 (NCSA) 诞生。是的，那么老。目标是开发一种结合灵活性和效率的文件格式来处理超大型数据集。不知何故，HDF 文件并没有被主流使用，因为只有少数行业确实能够真正利用它的可怕的能力，或者根本不需要它们。
FLEXIBILITY 意味着文件结构承担了一些开销，如果数组的内容没有变化，则不需要使用（您付出成本而不消耗任何好处使用它）和一个假设，即HDF5 限制它可以包含的数据的整体大小有助于并保存问题的 MATLAB 方面是不正确的。
MAT-files 原则上是好的，因为它们避免了将整个文件加载到 RAM 中以便能够使用它的持续需要。
尽管如此，MAT-files 并不能很好地完成此处定义和阐明的简单任务。尝试这样做只会导致性能不佳和 HDD-IO 文件碎片化（在 write-through-s 期间增加几十毫秒，而在 @987654343 @-s 在计算期间）对判断整体性能不佳的核心原因毫无帮助。
专业的解决方案
而不是将整个巨大的 1E12 DataELEMENTs 集合移动到一个 MATLAB 内存代理数据数组中，这只是为下一个即将到来的HDF5/ MAT-file HDD-device IO-s（write-throughs 和 O/S 与硬件设备链冲突/次优化 read-aheads），以便让所有巨大的工作“刚刚 [结婚] 准备好”对于 mean() / max() MATLAB 函数的一些简单的调用（这将尽最大努力改进每个 1E12强> DataELEMENTs 只是另一个顺序（甚至两次 -- 是的 -- 在第一次工作处理噩梦之后，另一个马戏团一直在下降，通过所有的 HDD- IO 瓶颈 ) 回到 MATLAB in-RAM-objects，重新设计这一步从一开始就进入管道 BigDATA 处理。
while true % ref. comment Simon W Oct 1 at 11:29
[ isStillProcessingDotNET, ... % a FLAG from .NET reader function
aDotNET_RowOfVALUEs ... % a ROW from .NET reader function
] = GetDataFromDotNET( aDtPT ) % .NET reader
if ( isStillProcessingDotNET ) % Yes, more rows are still to come ...
aRowCOUNT = aRowCOUNT + 1; % keep .INC for aRowCOUNT ( mean() )
for i = 1:size( aDotNET_RowOfVALUEs )(2) % stepping across each column
aValue = aDotNET_RowOfVALUEs(i); %
anIncrementalSumInCOLUMN(i) = ...
anIncrementalSumInCOLUMN(i) + aValue; % keep .SUM for each column ( mean() )
if ( aMaxInCOLUMN(i) < aValue ) % retest for a "max.update()"
aMaxInCOLUMN(i) = aValue; % .STO a just found "new" max
end
endfor
continue % force re-loop
else
break
endif
end
%-------------------------------------------------------------------------------------------
% FINALLY:
% all results are pre-calculated right at the end of .NET reading phase:
%
% -------------------------------
% BILL OF ALL COMPUTATIONAL COSTS ( for given scales of 1E5 columns x 1E6 rows ):
% -------------------------------
% HDD.IO: **ZERO**
% IN-RAM STORAGE:
% Attr Name Size Bytes Class
% ==== ==== ==== ===== =====
% aMaxInCOLUMNs 1x100000 800000 double
% anIncrementalSumInCOLUMNs 1x100000 800000 double
% aRowCOUNT 1x1 8 double
%
% DATA PROCESSING:
%
% 1.000.000x .NET row-oriented reads ( same for both the OP and this, smarter BigDATA approach )
% 1x INT in aRowCOUNT, %% 1E6 .INC-s
% 100.000x FLOATs in aMaxInCOLUMN[] %% 1E5 * 1E6 .CMP-s
% 100.000x FLOATs in anIncrementalSumInCOLUMN[] %% 1E5 * 1E6 .ADD-s
% -----------------
% about 15 sec per COLUMN of 1E6 rows
% -----------------
% --> mean()s are anIncrementalSumInCOLUMN./aRowCOUNT
%-------------------------------------------------------------------------------------------
% PIPE-LINE-d processing takes in TimeDOMAIN "nothing" more than the .NET-reader process
%-------------------------------------------------------------------------------------------
您的 管道d BigDATA 计算策略将以一种智能的方式原则上避免 MATLAB 中的临时存储缓冲，因为它将逐步计算结果不超过大约 3 x 1E6 ADD/CMP-registers，全部采用静态布局，避免代理存储到HDF5/MAT-file，绝对避免所有与 HDD-IO 相关的瓶颈和低 BigDATA 持续读取速度（根本不谈论临时/BigDATA 持续写入......），并且将 还将避免 表现不佳的内存映射使用仅用于计算均值和最大值。
结语
管道处理在阳光下并不是什么新鲜事。
它重用了以速度为导向的 HPC 解决方案已经使用了几十年
[ BigDATA 标签在营销部门的“发明”之前的几代人。 ]
忘掉无数 HDD-IO 阻塞操作，进入流水线分布式进程到进程解决方案。
没有比这更快的了
如果是，那么所有外汇业务和高频交易对冲基金怪兽都已经存在了......