¿Cuánto cuesta un poco de lluvia?

Medido el 28 de septiembre de 2026 · Apple M4 Max · Una pantalla integrada

Weatherling dibuja lluvia en movimiento alrededor de tus ventanas, por lo que usa CPU, GPU y memoria mientras funciona. Varias personas han preguntado cuánto. Así lo mido, esto es lo que mostró la última prueba y esto es lo que falta comprobar.

En este Mac, las dos pruebas breves válidas con ajustes predeterminados promediaron 2,97–3,75 % de un núcleo de CPU y 375–391 MiB de memoria física. La prueba de cuatro horas consumió más memoria con el tiempo, hasta unos 467 MiB, antes de estabilizarse en la última hora. Son mediciones de una compilación en un equipo, no una promesa para todos los Macs ni sobre autonomía.

El Mac y la compilación que probé

Usé un MacBook Pro con Apple M4 Max, 64 GB de memoria y macOS 27.0. Su pantalla integrada tenía 3456 × 2234 píxeles a escala 2×, con una frecuencia declarada de 120 Hz. El Mac estaba enchufado. El brillo automático permaneció activo y seguí trabajando, con nueve ventanas visibles al inicio. No era un escritorio de laboratorio aislado y en reposo.

La app era una compilación Release local, versión 1.3 (compilación 3), basada en el commit 0ed73f4 con cambios locales adicionales de audio y seguimiento de entrada registrados con la prueba. Release usa optimizaciones de producción; no significa que ese ejecutable sea el disponible en el App Store. Guardé una copia antes de medir para que los cambios posteriores no sustituyeran el ejecutable probado.

Cómo funciona una prueba

Mido la app nativa dibujando lluvia en el escritorio. Una animación del navegador, una captura o una prueba de renderizado fuera de pantalla no revelan el coste completo de mantener una capa activa entre ventanas abiertas. Los ajustes temporales hacen repetible cada fase sin sobrescribir las preferencias del usuario.

1. Empezar con la app cerrada. Registrar un minuto de referencia del sistema e iniciar la app con la lluvia desactivada. Esperar 30 segundos y medir durante tres minutos.
2. Ejecutar la lluvia predeterminada. Usar intensidad 0,35, calidad Automática a 30 fps, viento y profundidad fijos, sin sonido ni partículas cercanas. Calentar dos minutos y medir diez.
3. Ejecutar lluvia intensa. Usar intensidad máxima, calidad Fluida a 60 fps, partículas cercanas y sonido. De nuevo, calentar dos minutos y medir diez.
4. Repetir tres veces. Las repeticiones muestran variaciones que una sola cifra favorable ocultaría. Terminar con otra referencia con la app cerrada.
5. Dejar la lluvia predeterminada durante cuatro horas. Tras otro calentamiento, registrar memoria y CPU durante la sesión larga, incluida la tendencia al final.

La secuencia completa dura unas cinco horas y media. La herramienta mantiene la pantalla despierta y los ajustes temporales permiten lluvia sobre apps a pantalla completa. Son condiciones de medición, no pruebas del comportamiento normal en reposo. Las trazas de GPU, observaciones de red y la captura del mapa de memoria se ejecutan fuera de los intervalos de muestreo de CPU y memoria. Reviso pausas, cierres inesperados y solapamientos del perfilador antes de aceptar un resultado.

Los últimos resultados

Los porcentajes de CPU consideran un núcleo como el 100 %, no el procesador entero. La memoria es la huella física, incluida la contabilidad gráfica; no la menor cifra de memoria residente que muestran algunas herramientas. Los resultados sin lluvia corresponden a inicios con el efecto desactivado, no a memoria retenida tras apagarlo.

Excluí por precaución la primera ronda predeterminada: una regla de exclusión pausó la lluvia al final del calentamiento, y la herramienta de capturas estuvo activa al empezar el muestreo. Todas las fases terminaron, pero solo obtuve dos rondas breves limpias. La CPU con lluvia intensa también varió mucho. Los cambios de actividad del escritorio impiden atribuir esa variación solo a Weatherling.

Por qué lo dejo funcionando cuatro horas

Diez minutos pueden pasar por alto asignaciones que se acumulan después. Durante la prueba larga, la memoria física pasó de 379,9 a 467,1 MiB, con un máximo muestreado de 469,7 MiB. Las medias por hora fueron 421,0, 435,0, 442,8 y 467,0 MiB. La última hora fue casi plana: su tendencia ajustada fue de unos +0,1 MiB por hora.

Esa estabilización final es un dato útil, pero no demuestra la ausencia de fugas. El crecimiento anterior merece investigarse. La CPU media de las cuatro horas fue el 5,64 % de un núcleo; el percentil 95 fue el 12,15 %, es decir, el 95 % de los intervalos quedó en ese nivel o por debajo. No se registraron pausas de ciclo de vida. Activar y desactivar repetidamente, reconectar pantallas y los ciclos de reposo necesitan pruebas aparte.

Trabajo de GPU y fluidez

Trazas separadas de Metal System Trace observaron unas 30 llamadas de presentación por segundo con calidad predeterminada y 60 con calidad alta. La media y el percentil 95 de tiempo activo de GPU por búfer de comandos fueron 0,307 y 0,758 milisegundos con ajustes predeterminados, y 0,375 y 0,596 con lluvia intensa. Como referencia, un fotograma a 30 fps dispone de 33,3 ms; a 60 fps, de 16,7 ms.

Cada traza cubrió unos 31 segundos. Hubo un intervalo entre llamadas superior a 50 ms con ajustes predeterminados y 15 superiores a 25 ms con lluvia intensa. Estas llamadas ayudan a describir el ritmo, pero no miden directamente la latencia de pantalla ni cuentan con exactitud los fotogramas perdidos. El tiempo de ejecución de GPU tampoco es un porcentaje de utilización. Separo el coste del perfilador de las mediciones largas de CPU y memoria.

¿Y la autonomía?

Esta prueba no permite decir cuántos minutos resta Weatherling a una carga. Recogí estimaciones de consumo del sistema durante las rondas breves y observé WindowServer, el proceso de macOS que compone el escritorio. Esas lecturas incluyen otras apps y el trabajo cambiante. Restar dos lecturas de un sistema ocupado no daría una potencia fiable atribuible solo a la app.

El registro energético comenzó a mitad de la primera fase con la app desactivada y terminó pronto en la prueba larga. Por tanto, faltan muestras de consumo de la referencia inicial y de casi toda la fase de cuatro horas. Para afirmar algo útil sobre autonomía hacen falta pruebas controladas sin enchufar, brillo y carga constantes y comparaciones con la app abierta y cerrada. Aquí no he completado esa prueba.

Cómo mantengo el rigor de las mediciones

El muestreador de CPU lee contadores de procesos de macOS, con la conversión temporal comprobada contra un reloj de CPU de proceso. Mide memoria física y E/S de disco cada dos segundos aproximadamente. Guardo el hash del ejecutable, la versión, el estado del código, los ajustes, las horas y los registros de ciclo de vida para vincular cada resultado a su ejecución. El perfilado terminó antes de los intervalos medidos y los ajustes guardados no cambiaron después.

Las capturas breves de red solo describen esos intervalos; una captura vacía no garantiza ausencia de red durante toda la vida de la app. Del mismo modo, cero escrituras físicas no implica cero actividad lógica de archivos. Conservo las trazas originales localmente porque pueden contener información de otros procesos del Mac. Esta página publica los resultados agregados y las condiciones.

Aún necesito medir Macs menos potentes, pantallas externas, uso con batería, modo de bajo consumo y transiciones sistemáticas de reposo y pantallas. Esta prueba tampoco aísla el coste de cada Ling. Las próximas mediciones repetirán la secuencia cuando sea posible, indicando los cambios de equipo, ajustes y compilación en vez de mezclarlos en una única cifra.

Si el rendimiento es distinto en tu Mac, envía un informe con el modelo, la versión de la app, las pantallas y los ajustes de lluvia. Esos detalles permiten convertir una inquietud general en una prueba reproducible.