1

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

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

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

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

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

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

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

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

你能接受所有的答案吗？

4

4 回答 4

1

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

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

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

于 2008-12-19T09:35:16.733 回答
1

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

如果是，您应该研究观察者设计模式以摆脱 SendMessage()。我已经将它用于相同类型的用例，并且对我来说效果很好。

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

于 2008-12-19T09:46:41.950 回答
1

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

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

于 2008-12-19T10:51:37.093 回答
0

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

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

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

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

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

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

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

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

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

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

于 2008-12-19T11:04:53.573 回答