Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

391
Visualizações
Reusing JSONDecoder or recreating it on every request?

In an asynchronous environment is it more efficient to use one JSONDecoder for all request (Might result in delays if multiple threads are waiting for the lock) or it's more efficient to create a new JSONDecoder for every new request?

Apple documentation says that the JSONDecoder class is reusable but they don't elaborate further.

https://developer.apple.com/documentation/foundation/jsondecoder

over 4 years ago · Santiago Trujillo
1 Respostas
Responde à pergunta

0

On Apple platforms, JSONDecoder relies on JSONSerialization for its initial parsing, and then creates a fresh __JSONDecoder (internal class) to actually do the decoding. It passes an _Options, which is a struct, so that's copied. So there shouldn't be any interaction at all between the threads as long as you're not changing the options (which is not thread-safe).

So it's probably slightly cheaper to reuse the same decoder, since it avoids allocating and deallocating a class instance, which is usually a win over just retaining and releasing a class instance (and I would expect that to be the case here). But I would expect the difference to be very, very small compared to the much larger cost of JSON decoding.

In fact, if I had a situation where this were actually worth profiling (and you would need to profile it to know if it's faster or not), I'd be asking "why in the world am I decoding this many different JSON messages this quickly?" For this to matter, the JSON probably wouldn't be coming from the network or disk (those are so insanely slow to make one extra class allocation meaningless). It would only matter if you were working JSON that is already in memory in huge numbers of small messages. And in that case, the answer would almost certainly be "stop using JSON for that problem."

But I expect that in almost all cases, this just doesn't matter, and I definitely would not proactively optimize it. Implement whichever is clearer in your code. Then profile the code to see where your bottlenecks are.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda