Go에는 채널이 있기 때문에 표준 라이브러리가 IO 용 채널을 사용하도록 설계되지 않은 이유가 궁금합니다.IO 채널 대 리더/라이터
그 대신 판독기 및 기록기 유형이 있지만 채널을 사용할 때의 문제점은 무엇입니까?
함수는 바이트 슬라이스 채널을 반환 할 수 있으며 (싱글 바이트 또는 단일 비트 리턴이 너무 비효율적이라고 가정) 취소 요청을위한 채널과 오류보고를위한 채널을 가져올 수 있습니다.
- 호기심 초보자.
채널은 goroutines 간의 통신에 적합합니다. 프로그램이 stdin을 읽는 것과 같이 간단한 일을 할 때, 스트림으로 무언가를하고 결과를 stdout으로 출력 할 때 - 채널을 사용하는 것은 지나치게 과장되어 성능을 불필요하게 손상시킵니다.
표준 라이브러리가 서로 통신하는 goroutines에 특정한 특정 항목을 제공하지 않는 한 채널을 사용하는 io.Reader 또는 io.Writer과 같은 간단한 조작을 모델링 할 충분한 이유가 없습니다 메소드 세트 (API).
또한 필요한 경우 채널 구현을 채널에 래핑 할 수 있으며 반대쪽 채널 구현을 기본 요소로 되돌릴 수는 없습니다. 또한 Go 작성자는 명백히 explicitness를 좋아해 성능 병목 현상을 숨기지 않고 (놀라운) 수행합니다.
그래서 두 가지 사실을 모았습니다. 1) 채널은이 경우 성능 병목 현상이 될 것이며 2) 채널은 IO를 숨기고 디자이너는이를 좋아하지 않습니다. 실제 성능 저하가 무엇인지 파악하기 위해 리더/라이터 대 채널의 성능 측정을 수행하는 것이 흥미로울 것입니다. 물론 컴파일러가 단순한 경우에 최적화 할 수 있고 최적화가 시간이 지남에 따라 더 복잡해질 것이라는 것을 깨달을 수 있습니다. Rob Pike는 채널에 대한 성능 최적화 기회에 대해 이야기했습니다. –