在Windows上加速文本输出,用于控制台

我们有一个具有一个或多个文本控制台窗口的应用程序,这些窗口基本上都是串行端口(文本input和输出,逐个字符)。 这些窗口已经成为目前代码的主要性能问题……我们设法在这些窗口花费大量的时间。

当前的代码是由窗口生活自己的小生活,主要应用程序线程通过“SendMessage()”调用驱动它。 这消息传递似乎是令人难以置信的开销的原因。 基本上,绕过操作系统感觉是不对的。

请注意,我们在适当的时候将文本行整体绘制成一个整体,以便轻松优化已经完成。

我不是Windows编码方面的专家,所以我需要问社区是否有其他架构来驱动窗口中的文本显示,而不是像这样发送消息? 它似乎相当重量级。

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

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

所以我想下面给出的所有build议是正确的:

  • 看看有多less东西重绘
  • 直接画东西
  • 大块绘图操作要及时,不要把每个字符都发送到屏幕上,瞄准串口控制台10〜20Hz的更新速度。

你能接受所有的答案吗?

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

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

你应该尝试正确的分析,但是我不会再担心SendMessage,这几乎肯定不是你的问题,而是考虑重新绘制窗口本身。

你描述这些是“文本控制台窗口”,但是然后说你有多个 – 他们实际上是Windows控制台? 还是他们的应用程序正在绘制?

如果是后者,那么我会考虑测量我的绘制代码,以及每次更新是否使得窗口过多失效。

输出窗口是同一个应用程序的一部分吗? 这听起来像是不是…

如果是的话,你应该查看Observer的设计模式,以避开SendMessage()。 我已经使用它的相同类型的用例,它为我工作的很好。

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

输出窗口是同一个应用程序的一部分吗? 这听起来像是不是…

是的,他们都在同一个过程中。

我没有写这个代码…但是好像SendMessage对于这个应用程序的情况有点沉重。

你描述这些是“文本控制台窗口”,但是然后说你有多个 – 他们实际上是Windows控制台? 还是他们的应用程序正在绘制?

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

请注意,我们还需要在用户键入控制台时返回数据,因为我们经常具有交互式串行会话。 可以把它看作与你在串口终端程序中看到的非常相似 – 但是使用外部应用显然比现在更昂贵。

如果你不能做这样的改变,也许你可以缓冲你的输出100毫秒的东西,这样你就不会有这么多的每秒钟外出的消息,但它也应该以一个舒适的速度更新。

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

当我们在换行时滚动窗口,然后我们逐行重新绘制。

请注意,我们也有一个任意大小的回滚缓冲区,但向后滚动是一个交互式的情况下性能要求低得多。