将使用多个线程加速我的HTML文件处理应用程序
本文关键字：HTML 我的 文件 处理 应用程序 加速 线程 | 更新日期: 2023-09-27 17:58:52
我刚刚完成了迄今为止最复杂、功能最丰富的WinForms应用程序。它加载一个任意数量的HTML文件列表，然后加载其中一个文件的内容，使用一些RegEx来匹配一些标记并删除或替换它们（是的，是的，我看到了。它工作得很好，谢谢Cthulu），然后将其写入磁盘。
然而，我注意到大约200个文件的处理大约需要30秒，在前5-10秒之后，程序报告为"未响应"。我认为像这家伙那样做是不明智的，因为硬盘是一个瓶颈。
也许可以将尽可能多的数据加载到内存中，然后用线程处理每个数据，写入这些数据，然后再将更多数据加载到存储器中？
至少，创建一个独立于UI线程的工作线程会防止"未响应"问题吗？（这篇MSDN文章涵盖了我正在考虑的内容。）
我想我在问多线程是否会提供任何形式的速度改进，如果是的话，最好的方法是什么？
非常感谢您的帮助或建议！
是的，您应该首先使用Backgroundworker将您的工作与GUI解耦。处理GUI事件不应该花费太多时间。目标是20毫秒，而不是20秒。
然后，作为奖励，您可以查看处理（CPU密集型部分）是否可以拆分为独立的作业，并将其作为TPL任务执行。
没有足够的信息来说明你是否应该或如何做到这一点。
在大多数情况下，线程作业、任务等将防止主线程或主线程变得无响应。不要为磁盘IO创建多个线程（显然）。我会用一个工作线程来从队列中取出文件并处理磁盘IO。否则，在主线程可以保持响应的情况下，1或2个工作线程在内存中处理应该足够了。
首先，如果您希望程序保持响应，请将计算移动到一个单独的线程（将其从UI线程中删除）。
实际性能的提高取决于处理器的数量，而不是线程的数量。
因此，如果您有p线程，您可以将工作划分为p工作项，并获得一些工作改进。（阿姆达尔定律）
您可以使用BackgroundWorker来正确分配工作C#BackgroundWorker教程
为什么不使用StreamReader.ReadAllLines（）将每个文件读取到数组中，然后处理数组的每个元素？
如果您在GUI线程中进行所有处理，那么如果花费很长时间，应用程序将显示"未响应"。在我看来，您应该尽量不要在与GUI相同的线程中执行（广泛的）处理操作。此外，您甚至可以为每个要处理的文件创建一个线程。只要独立的线程不需要来自彼此的任何数据，这很可能会加快速度。