소진될 때까지 페이지 크롤링하기
요구사항
페이지 단위 주문 API는 페이지당 주문 세 건을 반환하고, 데이터가 떨어지면(4페이지) 빈 리스트를 반환합니다. 빈 페이지가 나올 때까지 페이지를 하나씩 크롤링하고, 주문들을 하나의 리스트로 평탄화한 뒤, 그것들과 함께 실제로 가져온 페이지 수를 출력하세요 — 정확히 네 페이지입니다; 크롤은 결코 5페이지를 요청해서는 안 됩니다. 가짜 API는 코드에 들어 있습니다; 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.
예상 출력
order#1 order#2 order#3 order#4 order#5 order#6 order#7 order#8 order#9 pages fetched: 4
나란히 보기
RxDart
FxDart
차이가 나는 이유
페이지네이션은 그 자체가 풀 모델입니다: 페이지 하나를
가져오고, 들여다보고, 하나 더 요청할지 결정합니다. FxDart 쪽은
그것을 그대로 적어 내려갑니다 — 파이프라인이 다음 것을 요구할
때만 전진하는, 페이지 번호의 끝없는 sync* 커서,
map(fetchPage), takeWhile(isNotEmpty),
평탄화. 커서에 한계를 두는 것은 아무것도 없습니다. 요구가 곧
한계이기 때문입니다: takeWhile이 빈 페이지를 보면
그냥 풀기를 멈추고, 5페이지는 생성조차 되지 않습니다.
스트림 쪽도 같은 곳에 도달하지만, 풀 메커니즘을 빌려서만
가능합니다: 끝없는 async* 커서 — Rx 연산자가 아니라
순수 Dart — 를 일시 정지시켜 asyncMap의 배압으로
요구 주도 동작으로 만들고, takeWhile의 취소가 빈
페이지에서 크롤을 멈춥니다. 동작하고, 같은
pages fetched: 4를 출력합니다 — pause, resume,
cancel이 바로 "준비되면 다시 요청한다"를 흉내 내는 스트림 모델의
역방향 채널이기 때문입니다. 풀 쪽에는 그 흉내가 필요 없었습니다:
요구가 그것의 평상 모드입니다. 소비자의 상태가 입력이 더
존재해야 하는지를 결정하는 일은 풀 모양의 일이고, 이것은 그중
가장 깔끔한 사례입니다.
벤치마크
비동기 예제입니다. 대표 스케일이 1,000,000이 아니라 N = 10,000인 이유 — 원소 하나마다 양쪽 모두 이벤트 루프를 한 바퀴 돌아야 하므로, 실제 await 백만 번은 파이프라인이 아니라 Dart 이벤트 루프를 몇 분씩 재게 됩니다. 지연은 0으로 두고 예제의 동시성 제한은 그대로 유지합니다. 막대가 비교하는 것은 파이프라인 기계 장치 자체입니다.
N = 100
시간 무승부
최대 메모리 무승부
N = 10,000
시간 무승부
최대 메모리 무승부
막대는 사이드별로 새 프로세스에서 반복 측정한 중앙값입니다(작은 N은 타이머 해상도를 위해 배치 처리). 두 사이드가 서로 5% 이내이거나 — 사람이 지각할 수 없는 차이인 0.6ms 이내이면 — 무승부로 칩니다. 상대 차이가 근소한 경우는 최대 5회까지 다시 측정합니다. 앱에서는 어느 막대가 짧든 몇 밀리초 이하의 차이는 사용자에게 보이지 않습니다. 메모리는 프로세스 최대 RSS입니다. Dart VM과 데이터셋은 양쪽이 동일하므로, 두 막대의 차이가 곧 파이프라인 자체가 붙들고 있는 양입니다.