【发布时间】:2010-06-04 01:35:53
【问题描述】:
我必须创建一个能够很好地处理读取大文件的 C# 程序。
例如,我有一个 60+ mB 的文件。我将所有内容读入一个闪烁框,我们称之为 sci_log。该程序使用大约 200mB 的内存来实现此功能和其他功能。这仍然是可以接受的(并且小于 Notepad++ 用于打开此文件的内存量)。
我还有另一个闪烁盒,sci_splice。用户输入一个搜索词,程序在文件中搜索(如果文件长度足够小,则搜索 sci_log - 没关系,因为它是双向的)以找到 regexp.match。当它找到匹配项时,它将该行与具有先前匹配项的字符串连接起来,并增加一个临时计数变量。当 count 为 100(或 150 或 200,实际上是任何数字)时,我将输出放入 sci_splice,调用 GC.Collect(),然后重复接下来的 100 行(设置 count = 0,将字符串归零)。
我现在没有代码,因为我是用家用笔记本电脑编写的,但问题是它使用了很多内存。 200mB 的内存使用量跃升至 1gB 以上,而且看不到尽头。这仅发生在具有大量正则表达式匹配的搜索中,因此与字符串有关。但问题是,GC 不会释放内存吗?还有,为什么涨这么高?为什么它会超过三倍(最坏的情况)是没有意义的。即使所有 200mB 只是内存中的日志,它所做的只是读取每一行并存储它(最坏的情况)。
经过更多测试后,似乎 Scintilla 在添加行时使用大量内存存在问题。行的初始读取在几分之一秒内具有高达 850mB 的内存峰值。我想我只需要对输出进行分页。
【问题讨论】:
-
请不要在标题中包含标签(“C#”)。这就是标签的用途。
-
抱歉,我正要修复它。谢谢。
-
60MB 不是一个大文件。 2GB 是一个巨大的文件。
-
当然,但为了举例,我使用了 60mB。
-
调用 GC.Collect() 是个坏主意。它实际上可以导致对象生命周期被提升...
标签: c# .net memory-management scintilla