How to fix performance regression in serializing and deserializing JSON

In this episode of Sentry’s Snack of the Week, we’re going to dive into whether serialization and deserialization are always necessary steps. Let’s get into it.

How’s it going everyone, my name is Sarah and I’m Head of DevRel here at Sentry. Today we’re going to talk about…give me a minute, this is a tongue twister:

JSON serialization and deserialization

Specifically, how we might be able to improve performance, by eliminating some extra serialization and deserialization steps in between web requests…another tongue twister.

In web application development, serialization is when we convert an object into a JSON string. That JSON string then gets sent as part of a web request. When we get a response back we perform deserialization; which is converting that JSON string response into an object.

And this is exactly that default behavior that I want to challenge. There may be times when we can eliminate a deserialization and serialization step. For example, if we’re making two requests back to back, and the response from request number 1 is exactly what we want to send as part of request number 2, we don’t need to deserialize that response back into an object and then serialize it then immediately back into a JSON string. But what you do need to have is context. You need to make sure that that response is going to return exactly the object / serialized JSON string that you need for your next response. And if it does, that’s a perfect opportunity to reduce steps and maybe improve your performance.

Removing steps of deserialization and serialization may not always be the right move, but when it is it could really save you on your performance.

And don’t forget to like, subscribe and follow us on YouTube. You don’t want to miss anymore of these Sentry Snacks of the Week.

Watch the Next Snack >

Featuring

• 

  Sarah Guthals

  Head of Developer RelationsSentry