4개씩 배치로 업로드하기
요구사항
파일 열 개가 업로드 대기열에 있고 API는 요청당 최대 네 개를 받습니다. 대기열을 4개짜리 배치로 묶고(마지막 배치는 짧습니다) 각 배치의 크기와 id를 출력하세요. 데이터는 아래 코드에 있으며, 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.
예상 출력
batch of 4: img-01 img-02 img-03 img-04 batch of 4: img-05 img-06 img-07 img-08 batch of 2: img-09 img-10
나란히 보기
RxDart
FxDart
차이가 나는 이유
겹치지 않는 배칭은 두 모델 모두의 핵심 어휘이고, 둘 다 한 단어로
말합니다: bufferCount(4)는 이벤트 네 개를 모아
List로 내보내고, chunk(4)는 수요 한 번에 값
네 개를 List로 끌어옵니다. 둘 다 소스가 바닥나면 짧은
꼬리 배치를 흘려보냅니다. 각 배치를 포맷하는 map은 그
뒤로 글자 하나까지 동일합니다.
모델들이 갈라지기 시작하는 곳은 이 예제의 프레임 바로 바깥입니다.
스트림이 버퍼링하는 이유는 값이 자기 일정대로 도착하기 때문입니다 —
bufferCount에는 시간 기반 형제들(bufferTime)도
있는데, pull 파이프라인은 그것을 의도적으로 제공하지 않습니다.
소비자가 도착을 통제하는 세계에서 "지난 1초 동안 도착한 것"은 의미가
없기 때문입니다. pull 체인이 청크로 묶는 이유는 소비자가 네
개씩의 수요를 원하기 때문입니다 — chunk가 하류의
동시성과 곧바로 조합되는 이유이기도 합니다(다음 배치를 조립하는 동안
각 배치를 전송하기). 열 개짜리 고정 대기열에서는 어느 쪽의 장점도
발휘되지 않습니다: 무승부.
벤치마크
N = 100
시간 무승부
최대 메모리 무승부
N = 1,000,000
시간 FxDart 승
최대 메모리 무승부
막대는 사이드별로 새 프로세스에서 반복 측정한 중앙값입니다(작은 N은 타이머 해상도를 위해 배치 처리). 두 사이드가 서로 5% 이내이거나 — 사람이 지각할 수 없는 차이인 0.6ms 이내이면 — 무승부로 칩니다. 상대 차이가 근소한 경우는 최대 5회까지 다시 측정합니다. 앱에서는 어느 막대가 짧든 몇 밀리초 이하의 차이는 사용자에게 보이지 않습니다. 메모리는 프로세스 최대 RSS입니다. Dart VM과 데이터셋은 양쪽이 동일하므로, 두 막대의 차이가 곧 파이프라인 자체가 붙들고 있는 양입니다.