使用FileStreams的MimeKit迭代器

Question

我刚刚设法重写了一些代码，现在应该能够处理用于打印的大型MIME文件。

为此，我们以以下方式使用了MimeKit：

        var message = MimeMessage.Load(_fileStream, true);
        var iter = new MimeIterator(message);
        while (iter.MoveNext())
        {
        ...
        }

这里有趣的是，在我使用fileStream之前，我们用来复制HttpListenerRequest对象的inputStream，它是一个无法加载到MimeKit中的NetworkStream (不可查找的)。

自从添加了fileStream，对于2 2GB的任务，我在while循环中花费了大约40秒来迭代请求的每个部分，如果你问我，这是很多的……对于memoryStream，这是6秒。

这种行为正常吗？是否有机会使用MimeKit获得更好的时间，或者我应该实现我自己的解析器？

提前感谢！

Answer 1

这里有趣的是，在我使用fileStream之前，我们用来复制HttpListenerRequest对象的inputStream，它是一个不能加载到MimeKit中的NetworkStream (不可查找的)。

我不太清楚你上面的意思。你是在做这样的事情吗？

var memory = new MemoryStream ();
httpResponse.Stream.CopyTo (memory);
memory.Position = 0;
var message = MimeMessage.Load(memory, true);

自从添加了fileStream以来，对于一个2 2GB的任务，我在

循环中花费了大约40秒来迭代请求的每个部分，如果你问我，这是很多的……对于memoryStream，这是6秒。

使用MimeMessage.Load()时会将true作为persistent参数传递。这提高了解析性能(因为它不再需要在解析后将MIME内容加载到内存中)，但会对以后读取各个MIME部分的内容的性能产生负面影响，因为它需要在您请求时查找每个MIME部分的内容的_fileStream起始偏移量。

这种行为正常吗？

40秒看起来确实很多，但在不了解更多代码细节的情况下，我不能给出任何建议。

是否有机会使用MimeKit获得更好的性能，或者我是否应该实现自己的解析器？

好吧，我几乎可以保证，如果您实现自己的解析器，它很可能会比MimeKit慢几个数量级(就像用C#编写MIME解析器的其他尝试都比MimeKit慢几个数量级一样) ;-)

这里您需要做的是在分析器下运行您的代码，以查看问题所在。

如果性能问题是在循环中出现的，那么在解析器中就不是性能问题。这是你循环中的一个性能问题。这并不是说MimeKit代码不是造成速度变慢的原因。

如果问题出在MimeKit中，我会怀疑BoundStream.Read()中的逻辑：

// make sure that the source stream is in the expected position
if (BaseStream.Position != StartBoundary + position)
    BaseStream.Seek (StartBoundary + position, SeekOrigin.Begin);

在您的例子中，BaseStream应该是您的_fileStream。我看过FileStream.Position的代码已经有一段时间了，但它可能需要syscall才能获得那个值(并且syscall不是免费的)。

然而，40秒的时间比我预期的要多得多，除非每个MIME部分的内容都很庞大( MimePart.Content的流式内容将在每个循环中读取~4K，如果每个循环有1个lseek()，就可以累加起来)。

希望这能帮助你弄清楚这一点。