최신 검색만 중요할 때

우열 없음 async

요구사항

사용자가 쿼리 세 개를 입력합니다 — fx, 40 ms 뒤 fxdar, 그리고 잠시 뒤 fxdart. 각 검색은 150 ms 걸리므로, 첫 검색이 아직 진행 중일 때 두 번째 쿼리가 도착합니다: 첫 결과는 버려져야 하며, 결코 보이면 안 됩니다. 살아남은 결과들만 출력한 뒤, 시작된 검색 수 vs 전달된 검색 수를 출력하세요. 스케줄은 코드에 시뮬레이션되어 있습니다; 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.

예상 출력

7 results for "fxdar"
12 results for "fxdart"
searches started: 3, results delivered: 2

나란히 보기

RxDart

FxDart

차이가 나는 이유

다르지 않습니다. "더 새것이 옛것을 취소한다"는 구독에 대한 진술인데, fxEvents 레이어에도 구독이 있습니다: 그 switchMap은 각 쿼리를 내부 검색 스트림으로 매핑하고, 더 새 쿼리가 도착하는 순간 이전 것의 구독을 해지하므로, 뒤늦은 결과에는 닿을 리스너가 남아 있지 않습니다. 세 검색이 시작되고, 두 결과가 살아남고, 그 로직의 어느 것도 사용자 코드에 나타나지 않습니다 — 어느 패널에서도요. 손수 만든 에포크 카운터도, 완료 장부 정리도 없습니다.

fxdart는 정확히 이런 종류의 요구사항을 위해 Rx의 접근을 흡수했습니다: fxEvents는 평범한 Stream 위의 얇은 래퍼 체인으로 — 결코 extension이 아니어서 rxdart를 포함해 다른 어떤 스트림 라이브러리와도 공존합니다. RxDart의 연산자 카탈로그는 여전히 훨씬 큽니다; 살아남은 결과들에 진짜 값별 처리가 필요해지면 .pull()로 타입 있는 pull 체인으로 건너가세요. switchMap을 정의하는 사용 사례에서 두 패널은 연산자 대 연산자로 동등합니다: 무승부입니다.

벤치마크

이 예제에는 벤치마크가 없습니다. 이 연산자는 처리한 일의 양이 아니라 흘러간 시간으로 정의됩니다. 양쪽 모두 똑같은 시간 창을 기다리므로, 막대는 두 라이브러리가 아니라 Dart의 타이머를 재게 됩니다. 시간 창을 줄여도 해결되지 않습니다 — 그러면 한 번의 이벤트 폭주에서 몇 개의 값이 나오는지가 머신 속도에 좌우되고, 두 구현이 같은 결과를 냈는지 대조할 수 없게 되기 때문입니다. 타이밍 연산자로 만들어진 예제들을 측정하지 않고 두는 이유가 이것입니다. 지연이 그저 I/O를 흉내 낼 뿐인 예제들은 그 지연을 0으로 두고 벤치마크합니다.