Conserva valores Y fallos en la auditoría

Gana FxDart

Requisito

Una auditoría de despliegue parsea ocho líneas de configuración key=value, tres de las cuales tienen valores imposibles de parsear. El informe necesita ambas mitades: imprime cada key = value parseado con éxito, y luego un recuento de los fallos. Las líneas están en el código; las dos versiones deben imprimir la salida que aparece bajo Salida esperada.

Salida esperada
timeout = 30
port = 8080
workers = 4
ttl = 300
batch = 25
failures: 3

Lado a lado

RxDart

FxDart

Por qué difieren

El modelo stream lleva los errores por un canal aparte, fuera de banda — y ese canal es terminal: una sola FormatException termina la suscripción entera, llevándose las cinco líneas buenas con ella. Para conservar valores y fallos, el lado RxDart tiene que darle a cada línea su propio stream interno (Rx.fromCallable) y convertir el error en datos antes de que pueda escapar — onErrorReturn(null) aquí, con null haciendo de «esta falló». Esa es la forma más ligera que el modelo permite para una función que lanza (la ruta más pesada de materialize reifica objetos de notificación completos), y existe solo para deshacer una decisión que el modelo tomó por ti: los errores nunca fueron valores desde el principio. (Los dos paneles comparten a propósito el mismo parse que lanza — con un parser que devolviera null ambos modelos podrían mantener los resultados como datos planos; el throw es la premisa, y lo que cada lado debe hacer al respecto es la comparación.)

El lado pull nunca pone los fallos en un canal, para empezar. El mismo throw aterriza a un try/catch local de distancia de volver a ser un valor ordinario — un record anulable — así que el requisito completo es map y luego partition: una pasada, dos listas, ambas mitades igual de primera clase. Esta es la forma de la postura más amplia de FxDart sobre errores tipados (sus pipelines de Either son esta misma idea con tipos de error más ricos). Cuando los fallos son parte del informe y no un final excepcional, mantenerlos como datos gana — el veredicto se lo lleva FxDart.

Benchmark

Apple M1 Max, 32 GB de RAM · Dart 3.12.2 (compilado AOT) · 2026-08-18

N = 100

Tiempo Empate

RxDart 465 µs
FxDart 100 µs

Memoria pico Empate

RxDart 16.6 MB
FxDart 16.4 MB

N = 1,000,000

Tiempo Gana FxDart

RxDart 3894.3 ms
FxDart 995.7 ms

Memoria pico Empate

RxDart 184.3 MB
FxDart 185.3 MB

Las barras son medianas de iteraciones cronometradas repetidas en procesos nuevos por lado (los N pequeños se agrupan por resolución del temporizador). Dos lados a menos del 5% entre sí — o a menos de 0.6 ms, una diferencia que nadie puede percibir — cuentan como empate; las carreras relativas ajustadas se vuelven a medir hasta 5 veces. En una app, cualquier cosa por debajo de unos pocos milisegundos es invisible para el usuario, gane la barra que gane. La memoria es el RSS pico del proceso. La VM de Dart y el dataset son idénticos en ambos lados, así que la diferencia entre las dos barras es lo que retiene el pipeline en sí.