在过去的几个月里，我一直在开发一个应用程序，它使用 Ghostscript.net 将 PS 文件转换为 PNG，然后将它们合并到另一个 PDF 文档中。
有 100 多个 PS 文件可以转换为 PNG。这是通过 Ghostscript.net 完成的，并且是多线程的。我没有发布任何代码，因为我认为我的问题不一定与代码相关。在过去的几个月里，我已经对该程序进行了数百次测试，没有出现任何问题。昨天我又去测试了，多线程部分运行的非常慢。在这部分 CPU 使用率徘徊在 100% 左右，但输出的生成时间呈指数增长。
我尝试运行此应用程序的较旧、更稳定的版本，但遇到了同样的问题。我还将它正在运行的文件数量减少到只有 1 个 PS 文件，但它的运行速度仍然非常慢。任何超过 4 个 PS 文件的文件都会在尝试运行大约 5 分钟后“超时”或引发异常。
我在其他计算机上运行我的应用程序，内存和处理能力更少，其他计算机运行它没有问题。
我的问题基本上是，我的机器可能发生了什么导致这些问题？哪里是开始调查的好地方。我使用的是工作电脑，所以我的访问级别是有限的。当我只用 4 个 PS 文件运行程序时，转换过程花了很长时间，但之后执行的代码似乎没有性能问题。我正在使用带有 Intel core i7 和 16GB RAM 的 Windows 7 机器。
编辑：所以我已经确定了这个问题（并认为它使这个问题与这个论坛更相关）。通常，当使用 Ghostscript 应用程序将 .ps 转换为 .pdf 时，会为每个输出文件创建一个临时文件。应用程序终止后，会话中创建的临时文件将被删除。我深入研究了 AppData\Temp\ 中的临时文件（经过更多研究，我现在知道 Ghostscript 将使用 TEMP 环境变量来确定这些文件的存储位置）并注意到有一堆 _teXXXX。 tmp 文件（略超过 65,000 个）。我还注意到这些 _teXXXX.tmp 文件都以数百个为一组，具有相同的创建日期/时间。
显然，当使用 Ghostscript.net dll 时，这些文件不会被处理掉。有一段时间，您不会看到减速，因为当 dll 请求临时文件名时，它会继续计数并返回一个文件名块。经过几个月的测试，它一定是用尽了它所使用的命名约定中的可用名称，导致它开始变慢（搜索整个范围以找到一个未使用的名称），然后最终导致它停止运行所有一起。
删除所有这些临时文件后，我的应用程序运行正常。
Ghostscript.NET 处理器对象有一个“Dispose()”方法，但这似乎并没有解决问题。当我在多线程环境中进行这些转换时，我将尝试以单线程方式运行它们，看看问题是否仍然存在。我将此作为错误提交，因为目前我似乎无法找到解决方案。现在，我将只实现一些代码并在运行完成后自己删除这些文件。