100 ms마다 호출 하나
요구사항
속도 제한이 있는 엔드포인트에 핑 다섯 번을 보내되, 각 호출은 이전
호출보다 최소 100 ms 뒤에 시작해야 합니다.
모든 호출의 시작을 단조 Stopwatch에 기록하고, 다섯
개의 응답을 출력한 뒤, 모든 간격이 제한을 지켰을 때만
spaced: true를 출력하세요. 두 버전 모두
예상 출력 아래에 표시된 줄들을 출력해야 합니다.
예상 출력
pong #1 pong #2 pong #3 pong #4 pong #5 spaced: true
나란히 보기
RxDart
FxDart
차이가 나는 이유
페이싱은 시간에 관한 일이므로 스트림이 이길 것이라 기대할 수
있습니다 — 그리고 실제로 RxDart에는 그것을 가리키는 단어가
있습니다: interval이 각 이벤트를 핑에 닿기 전에
100 ms씩 붙들어 두고, 배압이 전체를 순차로 유지합니다.
연산자 하나, 요구사항 충족.
하지만 풀 파이프라인은 기본이 순차이고, 그것이 페이싱을 민망할
만큼 단순한 일로 바꿉니다: 지연을 매퍼 안에 넣으세요. 각
풀이 100 ms 기다렸다가 호출합니다 — 이번 풀이 끝나기 전에는
다음 풀이 시작될 수 없으므로 간격은 구조적이고, 연산자는 필요
없습니다. Stopwatch 검증은 양쪽 모두 spaced: true를
출력합니다. 양쪽에 단서 하나씩 붙은 무승부라 부르겠습니다:
RxDart는 개념에 명시적으로 이름을 붙이고, 이는 다른 시간
연산자들로 가득한 파이프라인에서 더 잘 읽힙니다; FxDart는 그것을
요구의 한 줄짜리 귀결로 얻지만, 이 과제가 엄격히 직렬인 호출을
원하기 때문일 뿐입니다 — 자기 일정대로 도착하는 이벤트(진짜
이벤트 스트림)의 간격 조절에는 다리의 스트림
쪽(fxStream)과 RxDart의 시간 어휘로 손을 뻗으세요.
벤치마크
이 예제에는 벤치마크가 없습니다. 이 연산자는 처리한 일의 양이 아니라 흘러간 시간으로 정의됩니다. 양쪽 모두 똑같은 시간 창을 기다리므로, 막대는 두 라이브러리가 아니라 Dart의 타이머를 재게 됩니다. 시간 창을 줄여도 해결되지 않습니다 — 그러면 한 번의 이벤트 폭주에서 몇 개의 값이 나오는지가 머신 속도에 좌우되고, 두 구현이 같은 결과를 냈는지 대조할 수 없게 되기 때문입니다. 타이밍 연산자로 만들어진 예제들을 측정하지 않고 두는 이유가 이것입니다. 지연이 그저 I/O를 흉내 낼 뿐인 예제들은 그 지연을 0으로 두고 벤치마크합니다.