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