从串行端口读取内存管理 - C#

发布于 2024-08-06 18:26:15 字数 346 浏览 5 评论 0原文

我正在开发一个程序,该程序从串行端口读取数据,然后解析、格式化并适当地显示信息。然而,该程序需要运行超过 12 个小时以上 - 不断处理传入的数据流。我发现当我让我的应用程序运行一段时间时,内存使用量以线性速率增加 - 不适合 12 小时的使用。

我已经实现了一个记录器,它将原始传入的二进制数据写入文件 - 有没有一种方法可以利用这个想法定期清除我的内存缓存?即,我如何经常以数据不需要存储在内存中的方式写入日志文件?

另外 - Windows 窗体应用程序的其他方面是否会对此做出贡献?例如,我将格式化的字符串打印到文本框,最终显示整个字符串。因为它运行了很长时间,所以它很容易显示数十万行文本。我应该将其写入文件并清除文本吗?或者其他什么?

I am working on a program that reads in from a serial port, then parses, formats, and displays the information appropriately. This program, however, needs to be run for upwards of 12+ hours - constantly handling a stream of incoming data. I am finding that as I let my app run for a while, the memory usage increases at a linear rate - not good for a 12 hour usage.

I have implemented a logger that writes the raw incoming binary data to a file - is there a way I can utilize this idea to clear my memory cache at regular intervals? I.e. how can I, every so often, write to the log file in such a way that the data doesn't need to be stored in memory?

Also - are there other aspects of a Windows Form Application that would contribute to this? E.g. I print the formatted strings to a textbox, which ends up displaying the entire string. Because this is running for so long, it easily displays hundreds of thousands of lines of text. Should I be writing this to a file and clearing the text? Or something else?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

冷夜 2024-08-13 18:26:15

显然,如果字符串随着时间的推移而增长,您的应用程序的内存使用量也会随着时间的推移而增长。此外,WinForms 文本框在处理非常大的字符串时可能会遇到问题。字符串有多大?

除非您确实想在屏幕上显示整个字符串,否则您绝对应该定期清除它(取决于用户的期望);这将节省内存并可能提高性能。

Obviously, if the string grows over time, your app's memory usage will also grow over time. Also, WinForms textboxes can have trouble dealing with very large strings. How large does the string get?

Unless you really want to display the entire string onscreen, you should definitely clear it periodically (depending on your users' expectations); this will save memory and probably improve performance.

孤独患者 2024-08-13 18:26:15

通常,.NET 中的内存管理是完全自动的。将短观察(分钟)推断为 12 小时期间时应小心。请注意,TaskManager 并不是一个很好的测量内存使用情况的工具。

写入传入数据不应显着增加内存使用量。但是有一些事情你应该避免做,一遍又一遍地连接字符串就是其中之一。您的 TextBox 的成本可能比您想象的要高得多。使用列表框会更有效。而且更容易。

Normally, memory management in .NET is completely automatic. You should be careful about extrapolating a short observations (minutes) to a 12 hour period. And please note that TaskManager is not a very good tool to measure memory usage.

Writing the incoming data should not increase memory usage significantly. But there are a few thing you should avoid doing, and concatenating to a string over and over is one of them. Your TextBox is probably costing a lot more than you seem to think. Using a ListBox would be more efficient. And easier.

红ご颜醉 2024-08-13 18:26:15

我有几个串行应用程序,它们既可以作为应用程序运行,也可以作为 Windows 服务运行。这些要求为 24/7-365。我发现避免同样问题的最佳机制有两个。

1) 将信息写入日志文件。对于服务来说,这是获取信息的唯一方法。日志文件不会增加您的内存使用量。

2) 对于应用程序,将信息写入日志文件并将其放入列表框中。我通常将列表框限制为最后 500 或 1000 个条目。使用较新的 .net 控件,列表框被虚拟化,这会有所帮助,但您也不会遇到其他内存问题,例如文本框串联。

您可以通过在几个小时内不断附加字符串来使用文本框关闭系统,因为它不适合开箱即用的滥用。

I have several serial applications which run either as an application or as a windows service. These are required to be up 24/7-365. The best mechanism I have found to avoid this same problem is two-fold.

1) Write the information out to a log file. For a service, this is the only way of getting the info out. The log file does not increase your memory usage.

2) For the application, write the information out to a log file as well as put it into a listbox. I generally limit the listbox to the last 500 or 1000 entries. With the newer .net controls, the listboxes are virtualized which helps but you also don't run into other memory issues such as the textbox concatenation.

You can take a system down with a textbox by constantly appending the string over a number of hours as it is not intended for that kind of abuse out of the box.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文