Hablo desde mi experiencia personal, puedo estar equivocado, obviamente. El performance siempre me ha importado pero en concreto llevo ya 3-4 años dedicandome principalmente a 2 cosas, 1 coger cosas lentas del sistema legacy para hacerlas más rápidas (o sustituirlas por un equivalente en el sistema nuevo que tiene todo mejor estructurado/indexado enbdd, etc...) y 2 hacer procesos que implican cruzar datos masivos que se ejecutan cada 10-20s por lo que no es aceptable que sea lento. Al punto de coger algunos procesos que por el volumen de crecimiento que ha tenido nuestro ecommerce que se habían disparado hasta los 100 minutos y utilizando las estructuras adecuadas y replanteandolo todo mejor es posible reducirla a 1 segundo asi de importantes son las estructuras adecuadas. Los bucles for simples siempre son más rápidos y los objetos literales siempre son más rápidos de acceder que los Set (imagino que porque tendrá que hacer checks de tipado internos que el objeto literal no hace), y en el caso de funcionalidades que requieran recorrer grandes cantidades de datos y cruzarlos con otros elementos siempre optar por una estructura key value antes que haces finds, filters, y pollas dentro de bucles. No recorrer con maps pues generan otro array (a no ser que sea el escenario para hacerlo) y usar un find antes que un filter y coger primera posición ya que tiene que iterar el array completo (esto parece mentira pero lo he visto muchas veces) El codigo quedará más verboso en lo que tiene que ver el setup de la función( es decir, tienes que hacer las estructuras antes de ejecutarlo) pero si usas nombres adecuados (y si usas TS, tipados adecuados) será igual o más facil de leer y la velocidad estará a otra escala. Para mi si es un endpoint que tiene que ser rápido y tiene mucho impacto es obligatorio, incluso si solo te ahorrase 5-6ms (por ejemplo, en nuestro ecommerce, todo lo que tiene que ver con realizar busquedas de productos o sliders de productos, que al final usan lo mismo en nuestro caso por detrás), por ejemplo cualquier búsqueda a nuestro elasticsearch para recoger una paginación de una categoría o un sliders de 16 productos tarda 0.5ms (previamente la estructura está tuneadisima para ir a tiro hecho, catalogo de 70K productos), si luego para montar la respuesta se recorren mal las estructuras de datos complementarias y se le añade gratuitamente tiempo merece la pena replantearla. Otra cosa es ya preocuparte por rascar 5ms en un proceso largo, en ese caso debería hacerse focus en eso que se lleve la mayor parte del tiempo y no hacer microoptimizaciones. PD: si usais ChatGPT para optimizar alguna función pequeña que teneis la certeza de que es el cuello de botella, revisad bien que hace lo mismo que la otra porque a mi casi me la cuela alguna vez, sobretodo con sorts, tenía un proceso de búsqueda de el mejor sitio para un pallet dentro del almacen y teniendo en cuenta una barbaridad de criterios tenía que hacer un super sort de todos ellos.
Lo que has ayudado a esta comunidad es increíble, no tiene precio gracias MIdu!
Gracias, amigo!
Me encantan este tipo de proyectos.
Gracias!!
@@midulive El agradecimiento te lo mereces tú.
Me encanta esto, gracias Midu, para uno que es buen junior que sea desde 0 esta mas wue genial
¡Espectacular! ❤
Muchas gracias 🙌🏽
Que grande eres Midu !!!! Que App tan increíble. Gracias por tanto aporte a la comunidad
Como amo aprender nuevas cositas super interesantes contingo midu, mil gracias
justamente esta semana trabaje con web workers, son un una herremienta muy util!!
Me encantan este tipo de proyectos, sigue subiendo
Sin Astro 😁 👏👏👏 Gracias por compartir!.
Gracias midu, se aprende muchísimo con estos videos!!
Dentro de los 100 proyectos de Javascript seria interesante desarrollar un Calendario.
realmente MARCA LA DIFERENCIA!!
Gracias por tanto!
Qué interesante midu, qué "fácil" se sintió. Ojalá poder ver uno de service worker para ver la diferencia.
Joder me perdí el en vivo 😢, espectacular esta serie que haces de todo sin dependencia y puro js wow
Que buen video sinceramente midu yiene un enorme corazón
Que buen video Midu, te amo!
Lo de dónde aprendimos el truco del field-sizing es totalmente cierto. Me saqué 10 risas en ese minuto ajajajajajja
grande midu gracias por los trucazos
Siiii. Parte dos
que grandee midudev!!!
Siempre he querido seguir tu directos en twitch,¿en que horarios los haces?
que utilizas midu? ese no es vsc?
Buenisimo, a darle.
Que pedazo de video🥵
Gracias, amigo!
Hablo desde mi experiencia personal, puedo estar equivocado, obviamente.
El performance siempre me ha importado pero en concreto llevo ya 3-4 años dedicandome principalmente a 2 cosas, 1 coger cosas lentas del sistema legacy para hacerlas más rápidas (o sustituirlas por un equivalente en el sistema nuevo que tiene todo mejor estructurado/indexado enbdd, etc...) y 2 hacer procesos que implican cruzar datos masivos que se ejecutan cada 10-20s por lo que no es aceptable que sea lento. Al punto de coger algunos procesos que por el volumen de crecimiento que ha tenido nuestro ecommerce que se habían disparado hasta los 100 minutos y utilizando las estructuras adecuadas y replanteandolo todo mejor es posible reducirla a 1 segundo asi de importantes son las estructuras adecuadas.
Los bucles for simples siempre son más rápidos y los objetos literales siempre son más rápidos de acceder que los Set (imagino que porque tendrá que hacer checks de tipado internos que el objeto literal no hace), y en el caso de funcionalidades que requieran recorrer grandes cantidades de datos y cruzarlos con otros elementos siempre optar por una estructura key value antes que haces finds, filters, y pollas dentro de bucles. No recorrer con maps pues generan otro array (a no ser que sea el escenario para hacerlo) y usar un find antes que un filter y coger primera posición ya que tiene que iterar el array completo (esto parece mentira pero lo he visto muchas veces)
El codigo quedará más verboso en lo que tiene que ver el setup de la función( es decir, tienes que hacer las estructuras antes de ejecutarlo) pero si usas nombres adecuados (y si usas TS, tipados adecuados) será igual o más facil de leer y la velocidad estará a otra escala.
Para mi si es un endpoint que tiene que ser rápido y tiene mucho impacto es obligatorio, incluso si solo te ahorrase 5-6ms (por ejemplo, en nuestro ecommerce, todo lo que tiene que ver con realizar busquedas de productos o sliders de productos, que al final usan lo mismo en nuestro caso por detrás), por ejemplo cualquier búsqueda a nuestro elasticsearch para recoger una paginación de una categoría o un sliders de 16 productos tarda 0.5ms (previamente la estructura está tuneadisima para ir a tiro hecho, catalogo de 70K productos), si luego para montar la respuesta se recorren mal las estructuras de datos complementarias y se le añade gratuitamente tiempo merece la pena replantearla.
Otra cosa es ya preocuparte por rascar 5ms en un proceso largo, en ese caso debería hacerse focus en eso que se lleve la mayor parte del tiempo y no hacer microoptimizaciones.
PD: si usais ChatGPT para optimizar alguna función pequeña que teneis la certeza de que es el cuello de botella, revisad bien que hace lo mismo que la otra porque a mi casi me la cuela alguna vez, sobretodo con sorts, tenía un proceso de búsqueda de el mejor sitio para un pallet dentro del almacen y teniendo en cuenta una barbaridad de criterios tenía que hacer un super sort de todos ellos.
gracias midu
genial proyecto, lastima que quitaste lo del highlight , pensaba que lo ivas a explicar más y lo quitaste :(
Divierte volver a la base de todo, y ver todo lo que es las bases.
👏👏👏
Que crack
1:21:48 en end game si pasa :u
No entendi, el priemro en resolverse no serie el 100% de por si ?
Oye oye sería chulo hacer una aplicación así pero para css
Aprendi cosas nuevas
Midu repasa el titulo de vídeo
11:17
Estas muy agresivo midu :V
eval is evil
aaa