En las plataformas de Apple , JSONDecoder se basa en JSONSerialization para su análisis inicial y luego crea un nuevo __JSONDecoder (clase interna) para realizar la decodificación. Pasa un _Options, que es una estructura, por lo que se copia. Por lo tanto, no debería haber ninguna interacción entre los subprocesos siempre que no cambie las opciones (que no es seguro para subprocesos).

Por lo tanto, probablemente sea un poco más barato reutilizar el mismo decodificador, ya que evita asignar y desasignar una instancia de clase, lo que generalmente es una ventaja sobre simplemente retener y liberar una instancia de clase (y espero que ese sea el caso aquí). Pero esperaría que la diferencia fuera muy, muy pequeña en comparación con el costo mucho mayor de la decodificación JSON.

De hecho, si tuviera una situación en la que realmente valiera la pena perfilarlo (y necesitaría perfilarlo para saber si es más rápido o no), estaría preguntando "¿por qué diablos estoy decodificando tantos mensajes JSON diferentes este ¿con rapidez?" Para que esto importe, el JSON probablemente no provendría de la red o el disco (son tan increíblemente lentos que hacen que una asignación de clase adicional no tenga sentido). Solo importaría si estuviera trabajando con JSON que ya está en la memoria en una gran cantidad de mensajes pequeños. Y en ese caso, la respuesta casi seguramente sería "dejar de usar JSON para ese problema".

Pero espero que en casi todos los casos, esto simplemente no importe, y definitivamente no lo optimizaría de manera proactiva. Implemente lo que sea más claro en su código. Luego perfile el código para ver dónde están sus cuellos de botella.