为控制台加速 Windows 上的文本输出

Question

我们有一个应用程序，它有一个或多个文本控制台窗口，它们基本上都代表串行端口（文本输入和输出，逐个字符）。这些窗口已成为当前代码方式的主要性能问题......我们设法在其中花费了大量时间。

当前代码的结构是让窗口过着自己的小生命，主应用程序线程通过“SendMessage()”调用驱动它。这种消息传递似乎是令人难以置信的开销的原因。基本上，绕道操作系统感觉是错误的做法。

请注意，我们会在适当的地方将文本行作为一个整体绘制，因此已经完成了简单的优化。

我不是 Windows 编码方面的专家，所以我需要询问社区是否有其他架构来驱动窗口中的文本显示而不是发送这样的消息？看起来很重量级。

请注意，这是使用 C++ 或纯 C 编写的，因为主应用程序是可移植的 C/C++/其他一些语言程序，也可以在 Linux 和 Solaris 上运行。

我们做了更多的调查，似乎一半的开销是使用 SendMessage 准备和发送每条消息，另一半是实际的屏幕绘制。 SendMessage 在同一文件中的函数之间完成...

所以我猜下面给出的所有建议都是正确的：

• 看看有多少东西被重绘了
• 直接画东西
• 及时分块绘制操作，不要将每个字符都发送到屏幕上，以实现串行控制台的 10 到 20 Hz 更新率。

你能接受所有答案吗？

Answer 1

我同意 Will Dean 的观点，即控制台窗口或文本框中的绘图本身就是性能瓶颈。您首先需要确定这不是您的问题。你说你把每条线画成一个整体，但如果数据吞吐量太高，即使这样也可能是个问题。

我建议您不要使用 SendMessage 将数据从主应用程序传递到文本窗口。相反，请使用其他一些沟通方式。这些是在同一个过程中吗？如果没有，您可以使用共享内存。在某些情况下，甚至磁盘中的文件也可以。让主应用程序写入该文件，文本控制台从中读取。您可以向文本控制台发送 SendMessage 通知，通知它更新视图。但不要在有新线路到达时发送消息。定义两个后续更新之间的最小间隔。

Answer 2

您应该尝试正确地进行分析，但作为替代，我将不再担心 SendMessage，这几乎肯定不是您的问题，而是考虑重绘窗口本身。

您将这些描述为“文本控制台窗口”，然后说您有多个 - 它们实际上是 Windows 控制台吗？或者它们是您的应用程序正在绘制的东西？

如果是后者，那么我会考虑测量我的绘制代码，以及我是否在每次更新时使太多的窗口无效。

Answer 3

输出窗口是同一个应用程序的一部分吗？听起来他们几乎不是……

如果是，您应该查看Observer design pattern 以避开 SendMessage()。我已经将它用于相同类型的用例，并且对我来说效果很好。

如果您不能进行这样的更改，也许您可​​以将输出缓冲 100 毫秒，这样您就不会每秒有太多的传出消息，但它也应该以舒适的速度更新。

Answer 4

输出窗口是 相同的应用程序？听起来差不多 好像他们不是……

是的，它们都在同一个过程中。

我没有编写此代码...但是对于这一切在一个应用程序案例中，SendMessage 似乎有点沉重。

你描述这些是'文本控制台 windows'，然后说你有 它们中的多个——它们实际上是 Windows 控制台？或者他们是 您的应用程序正在绘制什么东西？

我们的应用正在绘制它们，它们不是常规的 Windows 控制台。

请注意，我们还需要在用户输入控制台时取回数据，因为我们经常有交互式串行会话。可以将其想象为与您在串行终端程序中看到的非常相似——但使用外部应用程序显然比我们现在拥有的更昂贵。

如果你不能做出这样的改变， 也许你可以缓冲你的输出 大约 100 毫秒，这样你 没有太多外发消息 每秒，但它也应该更新 以舒适的价格。

好点子。现在，每个字符输出都会导致发送一条消息。

当我们在换行符出现时向上滚动窗口时，我们会逐行重绘它。

请注意，我们还有一个任意大小的回滚缓冲区，但回滚是一种交互式情况，性能要求要低得多。