I Told Old Zhang His Rust Service Might Be 10x Slower - He Almost Spit Coffee in My Face
Serde Macros Made Your Rust Service 10x Slower? Old Zhang’s Story
Yesterday afternoon, Old Zhang rushed to my desk with his laptop, looking like he’d just swallowed a lemon.
“Bro, help me out here. My Rust service is acting weird. The code looks fine, but once it’s deployed, it’s slow as molasses.”
I took his laptop and skimmed through the code. Honestly, at first glance, nothing seemed wrong. Rust is fast by nature - everyone knows that. It’s like Usain Bolt - even if you tried to slow him down, it’d be tough.
“Tell me the symptoms first,” I said to Old Zhang.
“It’s that debug logging feature,” Old Zhang pointed at a piece of code. “Product wanted to log every request payload for troubleshooting later. I thought it was simple - just add a serde_json::to_string and call it a day.”
I leaned in closer. Holy cow, this guy was doing JSON serialization in every single request processing flow.
“How many requests per second does this service handle?” I asked.
“We stress-tested it - around 50,000,” Old Zhang said.
I paused for a moment, then said: “Old Zhang, have you thought about what it means when you serialize the entire data structure 50,000 times per second?”
Old Zhang froze.
I gave him an analogy: “Imagine you run a package delivery station. Normally, you just glance at the address on the package and toss it into the right basket. That’s fast, right?”
Old Zhang nodded.
“Now,” I continued, “for ‘future reference,’ every time you receive a package, you open it up, take out everything inside, photograph each item, then repack it. You think that won’t slow you down?”
Old Zhang’s expression shifted from confusion to enlightenment.
“That’s the issue with Serde macros,” I explained. “Look at this line: #[derive(Serialize, Deserialize)]. Looks harmless at first glance. But this macro generates a ton of code at compile time, and that code does a lot of work at runtime.”
“Like what?” Old Zhang started paying attention.
“For example, if your struct has a String, serialization makes a copy. If you have a Vec with 10,000 numbers, serialization converts each number to a string and allocates memory for the JSON array. These operations seem trivial, but at 50,000 requests per second, the memory allocation frequency goes through the roof.”
I showed Old Zhang a piece of code:
use serde::{Serialize, Deserialize};
use serde_json;
#[derive(Serialize, Deserialize, Debug)]
struct Payload {
id: u64,
name: String,
values: Vec<u64>,
}
fn main() {
let payload = Payload {
id: 42,
name: "SuperLongStringThatKeepsAllocating".to_string(),
values: (0..10_000).collect(),
};
// Innocent-looking serialization
for _ in 0..1000 {
let _ = serde_json::to_string(&payload).unwrap();
}
}
“See, every loop iteration: allocates memory for the entire Vec
Old Zhang rubbed his chin: “So what do I do? I can’t just remove logging.”
“Of course not,” I said. “Think about it - do you really need to serialize on every request?”
Old Zhang thought for a moment: “Not really. I only need to log when there’s an error.”
“Exactly! So why not move the serialization into the error branch? Normal cases don’t execute it at all - only serialize when there’s an error. Much faster.”
Old Zhang’s eyes lit up: “Makes sense.”
“Also,” I added, “look at your struct - it has several Strings. You could change them to &str. That way, serialization doesn’t copy - it just borrows the original reference.”
I wrote him an optimized version:
#[derive(Serialize, Deserialize)]
struct Payload<'a> {
id: u64,
name: &'a str, // Use reference instead of String
}
“That’s like…” Old Zhang pondered.
“Like photocopying documents,” I jumped in. “String is like making a fresh copy every time. &str is like just showing someone the original - no copying needed. Which is faster?”
“Got it, got it,” Old Zhang nodded repeatedly. “Any other tricks?”
“Sure,” I said. “Think about it - your logs are for your own eyes, not for other systems to parse. Why use JSON? Use something like Bincode - a binary format that’s way faster.”
“What’s Bincode?”
“It’s a binary serialization format, much faster than JSON - about 5-6 times faster.” I showed him:
// Use Bincode instead of JSON
let encoded = bincode::serialize(&payload).unwrap();
“It’s like taking notes: writing Chinese characters by hand versus typing with a keyboard. Obviously typing is faster.”
Old Zhang immediately went back to fix his code.
About half an hour later, Old Zhang came back, grinning from ear to ear.
“Bro, it’s magic! I moved serialization to the error branch, changed String to &str, and switched to Bincode. Ran a stress test - performance is back, and CPU usage dropped by half. The optimization effect is so obvious.”
I patted his shoulder: “Remember this - Rust itself is fast, but even the fastest car struggles if you stuff two tons of bricks in the trunk. Serde macros aren’t bad - they’re great tools. But you need to understand what they’re doing.”
Old Zhang nodded repeatedly: “Learned my lesson.”
Here’s a summary - if you run into similar issues, here’s how to troubleshoot:
Step one: Make sure you’re compiling in release mode. Debug mode being slow is normal.
Step two: Use cargo flamegraph to see where CPU time is going. If you see serde_json or various clone functions taking up a lot, that’s probably your issue.
Step three: Check your code - are you serializing in places where you don’t need to? If data is just passing around inside your program, just pass references. Don’t go the JSON route.
Step four: If you really need serialization, consider faster formats like Bincode or MessagePack.
Step five: Don’t slap Serialize and Deserialize on every big struct. Create a lightweight DTO specifically for serialization, containing only the fields you need to serialize.
That’s how coding works - seemingly simple operations can hide massive overhead. Serde macros are convenient, like an all-you-can-eat buffet. But remember - eat too much and you’ll gain weight.
If This Article Helped You
If you found this useful, give it a like so more people can see it. Got questions or want to discuss? Drop a comment below, or follow my blog for more fun Rust stories. Share with friends who need it - let’s avoid these pitfalls together.