은 Console.WriteLine Windows 응용 프로그램의 병목 현상입니까?

Question

WPF 응용 프로그램이 있고 디버깅을 위해 콘솔에 표시되는 메시지가 있습니다. 이것은 Windows 응용 프로그램으로 구성되고 콘솔이 표시되지 않을 때 응용 프로그램의 성능에 영향을 줍니까?

Answer 1

Console.WriteLine()의 실제 병목 현상이 실제로 콘솔에 기록됩니다. 특히 콘솔을 스크롤해야 할 때 은 실제로입니다. 또한 Visual Studio 호스팅 프로세스에서 콘솔이없고 출력 창이 표시 될 때 출력을 캡처하는 상당한 오버 헤드가 있습니다.

앱을 배포 한 후에도 역할이 없습니다. 그러나 예, 모든 메서드 호출이 만들어지고 문자열이 형식화되는 중입니다. Windows API 함수가 콘솔이 없다는 것을 알게되면 가능한 마지막 순간에만 비트 버킷에 들어갑니다.

디버그 빌드에서 실행할 때 현재 앱에 허용되는 퍼센티지가있는 경우 걱정하지 마십시오. 디버거가없는 릴리스 빌드에서 별 ​​모양의 성능이 떨어지는 경우 Console.WriteLine()이 원인 일 수 있다고 생각되면 Search + Replace to Debug.Print()로 주저하지 마십시오.

Answer 2

병목 현상은 코드에서 가장 느린 지점이라는 것을 의미합니다. 우리가하는 모든 것을 알지 못한다면 그것을 알 수 없습니다.

성능에 미치는 영향은 있습니까? 그렇습니다. 아무 것도하지 않고있다. 뭔가를하고있다. 프로그램의 병목 현상이되기에 충분할 것인가? 나는 그것을 의심한다. 눈에 띄는 영향을 미치기에 충분할 것인가? 가능한 일이지만 가능성은 희박하다. 그것은 모두 당신의 프로그램이 무엇을하고 있는지에 달려 있으며 콘솔에 얼마나 쓰는지에 달려 있습니다. (시간이 걸리는 것을 알아 차리기 위해서는 꽤 많은 시간이 필요합니다.)

디버그시 출력을 볼 수 있도록 Console.WriteLine이 아닌 Debug.WriteLine을 사용할 수 있지만 릴리스 빌드를 컴파일하면 해당 명령문이 인쇄되지 않습니다.

Answer 3

무언가를하는 것은 아무 것도하지 않는 것보다 시간이 오래 걸립니다.

null 콘솔에 텍스트를 쓰는 행위는 주요한 성과는 아니며, 매개 변수로 전달할 내용과 어떤 볼륨이 될 수 있습니다.

콘솔 출력을 사용하거나 사용하지 않고 실제 성능을 측정하여 사용 패턴이 허용 오차 범위 내에 있는지 직접 확인하십시오.

Debug.WriteLine()은 릴리스에 맞게 빌드 할 때 자동으로 제외되므로 요구 사항에 따라 더 나은 선택이 될 수 있습니다.

Answer 4

자신의 로깅 프레임 워크를 빌드하고 최적화하려는 시도는 거의 최선의 방법이 아닙니다.

log4net과 같은 것을 보셨나요? 콘솔에 기록하는 것을 포함하여 다양한 appender를 구성 할 수 있습니다. 로깅 오버 헤드를 줄이기 위해 비동기 애펜더를 빌드 할 수도 있습니다.

에릭