2011-11-19 67 views
0

我有两种类型的文件。其中之一是ASCII文件,数据存储如下;ASCII文件解析速度

X Y Value 
0 0 5154,4 
1 0 5545455; 
. . ... 
. . ... 

另外一个是二进制文件。

我用StreamReaderReadLine()方法解析第一个方法,然后通过Split(' ')将值设置为double[,]数组。

我分析第二个与BinaryReader

解析二进制文件比ASCII文件快3-4倍。

问题1:读取ASCII文件比二进制文件慢。这是正常的吗?

问题2:你是否建议解析ASCII文件的另一种方法?

+0

读取文本并解析它以将数据转换为二进制文件比直接读取二进制文件要慢。慢3-4倍是不成问题的,尤其是如果文件被缓存(从而大大减少I/O时间)。向我们展示您用于解析的代码。 –

+0

在任何一种情况下,您都应该在解析之前将整个流读入内存。 –

+1

@DavidLively - 为什么?然后他会测量完全不同的东西;并且对于大文件(对于这种数据不是不合理的),它可能甚至不实用。 – Zarat

回答

3

这不是很多阅读ascii是慢,但你如何做到这一点。

它的解析,寻找新的生产线,分隔符,则文本的转换位为其他格式。 BinaryReader基本上是一个直接的内存拷贝。

这就像固定长度和CSV或CSV和XML您添加的更多的元数据之间的差异,更可以摆脱它,但更多的IT成本。

读通过字符的ASCII文件的字符可能制定出比的readline和分裂快,你可以优化它针对特定的文件结构。很多工作虽然非常脆弱,使其成为一个可疑的前景。加载到单独的线程可能甚至是并行处理线路,可能会更有收获,肯定会更令人满意并且可重用。

+0

起初,我通过char读取并解析了ascii文件char,但这种方式速度较慢。我想因为很多不规则的“空间”字符数。 –

+0

这里有方法和手段,但最终你的优化会取消彼此,并且非常复杂的代码可以完成一项简单的任务。如果你需要这样做,所有它真正说的是ascii是一个糟糕的选择。 –

3

从ASCII文件和二进制阅读没有什么不同,不同的是解析他们的,读你解析字符串倍增ASCII文件后,这是二进制文件了过程时间。但你读出的数据流是完全等于相当于二进制双数量并且不需要解析。

0

每月一次,我们收到有350万行的350 MB的csv文件,然后我们看它一次一行,并提出一些指标,它aprox的了。每次服务重新启动时60秒。
我制作了一个程序,将它烧成170万行,并将其转换为二进制格式,以达到24 MB。
这些数据在7 ms内直接读入内存,索引在需要时生成,数据在使用时转换。
内存消耗从400 MB降至90 MB。
问题的关键在于如果性能问题您应该选择适当的数据格式,同时请注意,此解决方案是唯一可能的,因为数据相当静态,并且数据在24小时内检索不到数百万次。
我相信现在的新服务实际上回复得比以前快了一点。