Executando verificação de segurança...
2

Não dá para definir claramente qual é o consumo de memória delas por uma razão muito básica. A especificação de EcmaScript (o nome correto de JavaScript) não diz nada como isso deve ser e cada implementação pode fazer com achar melhor, desde que não viole outros aspectos da especificação, inclusive sobre o que esses estados são.

Sabe-se que ocupa algum espaço e provavelmente não é pouco já que a linguagem tem tipagem dinâmica e isso exige uma infraestrutura mais complexa para cumprir esse objetivo. Há uma chance razoável de consumir o mesmo espaço e pode ser o mesmo de outros tipos simples (não inclui string, e array (obviamente object também).

Não se sabe, até olhar a implementação, se há um estado básico de qualquer valor já pode identificar se está indefinido ou nilo ou precisa de um objeto alocado para identificar isso. Eu não usaria o último se eu fosse um implementador. Mas o objeto de memória que identifica o tipo e um valor inicial não tem como escapar. Eu, como implementador, adotaria um padrão que em cima disso, sem precisar de um objeto auxiliar.

Talvez queira saber sobre o uso do Garbage Collector quando usa um ou outro. E ambos são considerados valores que não seguram valores úteis e portanto se algum objeto tinha uma variável o referenciando, quando o valor passa ser tanto null quanto undefined, a referência é perdida e o objeto é coletado em momento propício.

Então para efeitos de memória considere que ambos são iguais no que mais importa. Se precisar muito de um uso mais controlado, o que é bem raro em JS, você terá que testar em cada implementação para ver o comportamento e fazer da melhor forma para resolver o problema. E terá que monitorar porque em cada versão poderá mudar o comportamento.

Para entender mais veja essa pergunta que tem respostas que eu assino embaixo (as com mais pontuação). Mas o resumo é que o primeiro indica quew a variável não tem um valor definido, como o nome sugere, e o segundo tem um valor em estado considerado inválido, mas há um valor definido. A semântica de cada um é diferente e o segundo pode ter uma semântica até mesmo contextual, já que não tem uma definição universal do que é um valor inválido, só se sabe que é um valor e é considerado inválido.

Faz sentido para você?

Espero ter ajudado.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
1

Quanto à memória ocupada por null e undefined, é seguro dizer que não mais do que alguns bytes, e esse valor também varia de acordo com o ambiente de execução, mas no geral é bem pouco, irrelevante. Eu não consegui encontrar onde eu li essa informação, já faz um tempo, mas lembro que era uma análise completa da linguagem utilizando ferramentas de profiling de memória.