불안정한 API를 첫 성공까지 폴링하기

FxDart 승 async

요구사항

내보내기 작업의 상태 엔드포인트는 결정적으로 불안정합니다: 처음 네 번의 폴링은 pending을 응답하고, 다섯 번째는 ready를 응답합니다. 최대 열 번까지 폴링하면서 모든 폴링 기록을 로그로 남기고, 첫 성공에서 멈추고, 어느 시도가 성공했는지와 실제로 몇 번 폴링했는지를 보고하세요. 무작위성은 없습니다: 실패 횟수는 아래 코드에 고정되어 있으므로, 두 버전 모두 실행할 때마다 같은 결과를 출력합니다.

FxDart 버전은 재시도를 데이터로 씁니다: range(1, 11)이 폴링 일정이고, map이 전송이고, peek이 로그를 기록하고, dropWhile + head가 성공 정책입니다. 체인이 지연 평가되고 값을 한 번에 하나씩만 끌어오기 때문에, head가 폴링을 멈추게 합니다 — 실제로는 다섯 번의 요청만 이루어집니다.

예상 출력
polling export-2026-07 (up to 10 attempts):
  poll 1: pending
  poll 2: pending
  poll 3: pending
  poll 4: pending
  poll 5: ready
ready on attempt 5; polls actually made: 5

나란히 보기

네이티브 Dart

FxDart

차이가 나는 이유

솔직히 말하면: break를 쓴 네이티브 for 루프는 짧고, 이를 틀렸다고 할 사람은 없습니다. 차이는 각 부분이 어디에 놓이는가입니다. 루프 안에서는 시도 횟수 예산, 로깅, 성공 판정이 모두 제어 흐름 속에 뒤엉켜 있어서, 하나를 바꾸려면 본문 전체를 다시 읽어야 합니다. 파이프라인에서는 각 관심사가 이름 붙은 자기만의 단계이므로, 정책을 바꾸는 일(첫 성공 → 세 번째 성공, 변환 추가, 예산 확장)은 한 줄만 고치면 됩니다. 그리고 "승자 이후에는 폴링하지 않는다"는 지연 평가 보장은 FxDart에서 구조적으로 성립하는 반면, 루프에서는 break가 올바른 위치에 있는지에 달려 있습니다.

벤치마크

Apple M1 Max, RAM 32 GB · Dart 3.12.2 (AOT 컴파일) · 2026-08-24

비동기 예제입니다. 대표 스케일이 1,000,000이 아니라 N = 100,000인 이유 — 원소 하나마다 양쪽 모두 이벤트 루프를 한 바퀴 돌아야 하므로, 실제 await 백만 번은 파이프라인이 아니라 Dart 이벤트 루프를 몇 분씩 재게 됩니다. 지연은 0으로 두고 예제의 동시성 제한은 그대로 유지합니다. 막대가 비교하는 것은 파이프라인 기계 장치 자체입니다.

N = 100

시간 무승부

네이티브 Dart 556 µs
FxDart 645 µs

최대 메모리 무승부

네이티브 Dart 16.4 MB
FxDart 17.1 MB

N = 10,000

시간 네이티브 승

네이티브 Dart 48.2 ms
FxDart 55.5 ms

최대 메모리 FxDart 승

네이티브 Dart 29.5 MB
FxDart 24.5 MB

N = 100,000

시간 네이티브 승

네이티브 Dart 495.5 ms
FxDart 571.7 ms

최대 메모리 FxDart 승

네이티브 Dart 56.2 MB
FxDart 50.4 MB

막대는 사이드별로 새 프로세스에서 반복 측정한 중앙값입니다(작은 N은 타이머 해상도를 위해 배치 처리). 두 사이드가 서로 5% 이내이거나 — 사람이 지각할 수 없는 차이인 0.6ms 이내이면 — 무승부로 칩니다. 상대 차이가 근소한 경우는 최대 5회까지 다시 측정합니다. 앱에서는 어느 막대가 짧든 몇 밀리초 이하의 차이는 사용자에게 보이지 않습니다. 메모리는 프로세스 최대 RSS입니다. Dart VM과 데이터셋은 양쪽이 동일하므로, 두 막대의 차이가 곧 파이프라인 자체가 붙들고 있는 양입니다.