logo

midulive


Transcribed podcasts: 746
Time transcribed: 15d 5h 20m 39s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

Hay un artículo que si eres de esta gente que le encantan las microoptimizaciones y todo esto,
este artículo te va a encantar y vamos a repasar alguna cosa que te va a volar la cabeza.
Mira, se llama Optimizando JavaScript para divertimiento y provecho, ¿vale?
Para que te diviertas y aproveches de todo esto.
Y es un artículo muy interesante que tiene como 12 puntos en los que te dan algunas recomendaciones
de microoptimizaciones de JavaScript.
Digo microoptimizaciones porque este tipo de cosas muchas veces no son las que te van a marcar
la diferencia de que tu aplicación funcione bien o mal, a no ser que sea una aplicación
que necesitas que vaya al, vamos, al microsegundo.
Entonces, me ha parecido alguna muy interesante porque obviamente lo hace con datos y alguna
ya os digo que os va a sorprender.
Por ejemplo, punto 1. Evitar comparación de cadenas de texto.
¿Por qué? Pues resulta que las comparaciones de las cadenas de texto utiliza la cadena de texto,
no está utilizando el valor sino que está utilizando la referencia y eso parece que es más costoso.
En cambio, si utilizas números, utiliza directamente el valor.
Entonces, aquí te da el ejemplo de decir, oye, pues en TypeScript sería más interesante
que utilices números y que no utilices strings.
Y aquí tienes la diferencia de costes.
Fijaos que hace un loop de 100.000 elementos, ¿vale?
Y podéis ver la comparación.
Comparar con números es el doble de rápido que con cadenas de texto.
No está mal, o sea, esto yo la verdad no tenía ni idea, no me lo había planteado nunca.
Y dice eso, que si tú haces comparaciones de números es el doble de rápido que cadenas de texto.
Y hay más cositas, más cositas.
Este también está muy interesante, que es el tema de evitar diferentes formas.
¿Esto qué quiere decir?
Bueno, pues básicamente si tú te pones a pasar por parámetros diferentes formas de objetos,
se pierde la optimización que hace internamente V8, el motor de JavaScript que se está utilizando en Node.js, en Chrome y en muchos sitios.
Y aquí podéis ver, monomórfico.
¿Qué quiere decir monomórfico?
Que siempre se está pasando el mismo objeto.
Polimórfico.
Bueno, pues aquí podemos ver que hay diferentes objetos.
En este caso hay un objeto que sea diferente la forma.
Y megamórfico es básicamente que cada objeto que se está pasando, todos son diferentes.
Y si hacemos la comparación, fijaos la diferencia.
Cuando tú siempre estás pasando los mismos objetos con la misma forma, tiene un 100%.
Pero polimórfico, solo que con que cambies una vez el objeto que le pasas por parámetros, ya tiene una penalización de rendimiento brutal.
¿Y esto por qué?
Básicamente el navegador, o bueno, en este caso el motor, lo que hace es detectar el tipo de parámetro que le llega.
Y ve la forma del objeto y ya hace una precompilación, digamos.
¿Vale?
Ya dice, vale, pues voy a compilar y voy a separar este método aquí para saber que siempre exactamente utiliza esto.
Pero claro, si tú le vas cambiando el objeto que le vas pasando, pues la harías parda.
Tiene cositas muy interesantes.
No voy a pasarme por todas porque estaríamos aquí todo el día y la verdad es que me gusta un montón.
Pero hay un montón.
Por ejemplo, evitar métodos de array y de objetos.
A mucha gente le gusta justamente la programación funcional y que está súper bien la programación funcional.
Pero si hay una cosa que ya sabemos en muchos motivos de la programación funcional, es que la programación funcional tiene muchas ventajas, pero tiene un coste.
Y el coste suele ser el rendimiento.
Hay en algunos lenguajes que a lo mejor no, pero me refiero sobre todo y especialmente en JavaScript, que hay gente incluso que utiliza bibliotecas aparte.
Aparte, ya se sabe que el hacer cosas que sean mutables, la velocidad que tiene es mucho mayor.
Entonces aquí explica justamente esta diferencia.
Tenemos aquí funcional, que sería con un map, un filter, un reduce y aquí tendríamos imperativo, que esto es pues mutando y sumando y haciendo cosas y ya está.
Porque aquí estamos mutando todo el rato el resolve, estamos cambiando el valor y fijaos aquí la diferencia, que es hasta tres veces más rápida la forma imperativa.
Esto ya lo sabíamos, pero de nuevo, muchas veces este tipo de coste está justificado, porque si a lo mejor estás haciendo una página web y lo que quieres es mostrar 15 resultados, esto no sirve para absolutamente nada.
Pero hay veces que si tú tienes que ir al detalle y tiene que ser algo hiper mega rápido, pues a lo mejor esto sí que te puede marcar la diferencia.
O sea, está bien saberlo, pero tened cuidado con estas cosas.
Bueno, os recomiendo un montón que le echéis un vistazo, más que nada porque tiene hasta de estructuras de datos, evitar utilizar cadenas de texto y todo esto, está súper bien.
Echadle un vistazo, os he dejado el enlace, mira, Feral, os lo está dejando por ahí y estoy seguro que os ayudará para pillar algunas ideas cuanto menos, cuanto menos, ¿vale?
Pero ojo, que las optimizaciones prematuras las carga el diablo, ¿vale?
O sea, que tened cuidado que os conozco, que luego os volvéis todos locos ahí optimizando, ¿no?
Y haciendo en PRs y cosas locas.
Así que las micro optimizaciones las carga el diablo, ¿eh?
Tengan cuidado.