Heyho probó un poco con mapas frente a objetos en Javascript y descubrió que anular es mucho más rápido (2,5 veces) que poner el valor en indefinido o compararlo con simplemente eliminar la propiedad
Si se pregunta por qué siempre creo el mapa o el objeto JavaScript, lo hice para que cada prueba tenga la misma "sobrecarga".
EDITAR: también obtuve este que tiene un error lógico (establecer un valor de nulo a nulo o configurarlo de indefinido a indefinido) https://www.measurethat.net/Benchmarks/Show/15587/0/delete- vs-null-vs-indefinido-vs-void-0-vs-objectcreatenu
y aquí el resultado es un poco más extremo 4mio ops (de nulo a nulo) vs 4k ops (indefinido a indefinido)
Sé que la prueba no es realmente relevante, es puro interés, estoy preguntando :).
(Desarrollador V8 aquí.)
¡Los micropuntos de referencia son engañosos! No pierdas tu tiempo con ellos.
Establecer una propiedad de objeto en null o undefined tiene la misma velocidad. Garantizado.
Teniendo en cuenta la diferencia significativa que muestra su prueba de forma reproducible, sentí curiosidad y profundicé un poco. Resulta que el código del marco de trabajo de measurethat.net está... digamos... lejos de ser perfecto: usa " eval directa" de una manera que introduce enormes artefactos de rendimiento para acceder a globales (esa es una de varias razones por las que "nunca use eval directa". " es un consejo común), y uno de los accidentes históricos de JavaScript es que, si bien null es una palabra clave reservada, undefined es solo una variable global. Vea aquí lo ridículo que se vuelve:
https://www.measurethat.net/Benchmarks/Show/15627/0/accessing-null-vs-undefined
Si sabe lo que está pasando, puede eludir el problema:
https://www.measurethat.net/Benchmarks/Show/15635/0/null-vs-undefined-iiffe
Pero tenga en cuenta que en una aplicación real que no usa eval , no verá ninguna de estas diferencias; ¡solo estás jugando con un corredor de referencia malo allí!
Otra cosa que es realmente extraña en ese sitio es que al editar casos de prueba y "validarlos", producen resultados muy diferentes (¡he visto 100 veces!) en comparación con "ejecutarlos" después de enviarlos.
En resumen, no confiaría en ninguno de los números informados en ese sitio.
Dicho todo esto, tiene sentido que delete aa sea más lento, porque eliminar una propiedad de objeto es una operación más complicada que sobrescribir el valor de una propiedad existente. Es importante destacar (y su punto de referencia no muestra esto, porque es demasiado simple), la eliminación de propiedades a menudo tiene efectos no locales , es decir, no es la eliminación en sí lo que es necesariamente lento, pero otras partes de su aplicación pueden ralentizarse como efectos secundarios. . Por lo general, recomendamos no utilizar la palabra clave delete en absoluto. Eliminar entradas en Maps es una historia diferente: eso está perfectamente bien, ya que Maps está diseñado para admitir eso de manera eficiente.
Los objetos Javascript también deben tener en cuenta qué claves son "enumerables". Eliminar una clave la elimina de la lista de claves enumerables. Esto es similar a eliminar un elemento de una matriz, que es una operación más lenta que simplemente anular un valor con null .
No estoy seguro de por qué establecer el valor en undefined es más lento. Supongo que se debe a razones similares, ya que una clave faltante tiene un valor de undefined .
Diría que es porque delete realmente tiene que eliminar, en comparación con null que simplemente vaciará su contenido.
Un objeto con la propiedad 3000 que son nulos ocupa más espacio en el ram que un objeto vacío.
Si bien el rendimiento y los aspectos técnicos de JavaScript son muy interesantes, y el rendimiento en general no debe ignorarse por completo, esto es más que imperceptible y no debería importarle en escenarios de la vida real.
Este es mi entendimiento personal y no debe tomarse como información oficial. Siéntete libre de corregirme en los comentarios.