We ran into an interesting problem recently that I have not been able to find documented anywhere.
We're doing real-time USB data acquisition with .NET 2.0. The data bandwidth and processing isn't overwhelming. Specifically, we expect data packets at 50 Hz -- every 20 ms. Yet we were having horrible delay problems. In the end we found that Console.Writeline was the culprit!
To verify this a test program was written to measure the throughput of the following loop:
|
1 2 3 |
while (m_working) { Console.WriteLine(string.Format("Message {0} [{1}]",cnt++,mstr)); } |
The length of mstr is varied and this loop is run for about 30 seconds. The results show the ms per message for increasing message lengths:
Console.Writeline is surprisingly slow!
We use log4net for our logging. With the timestamp and class information, a log message is typically greater than 100 characters. A single log message introduces at least a 20 ms delay in that case, with additional messages adding that much more. Even though debug logging would not be included in the released version, these significant delays make development difficult.
Not only do you need to make sure that there are no Console.Writeline's in your real-time threads you also need to remove the console appender (<appender-ref ref="ConsoleAppender"/>) from the log4net configuration. The log4net file appenders do not cause noticeable delays.
38400 bps is the speed of the standard Linux console (it can be increased). This is an hardware independent performance problem…
It seems that Windows suffers from the same console architecture, thanks for the benchmarks (very usefull to prove performance issues to colleagues having a “fast computer processor” in mind while developping…) !
Michel Bagnol