4 ms·

As with everything performance related, it depends. I do server-side work as well, but I've seen cases where it matters. eg, somebody got overly "OO-happy" wit

As with everything performance related, it depends. I do server-side work as well, but I've seen cases where it matters. eg, somebody got overly "OO-happy" with a response object and managed to take something that should've been one object with 8 fields and instead made a graph of 8 object with a total of 12 fields (4 of them repeated), wasting ~400 bytes each IIRC. When you're creating one of those for each request and handling 200k requests/sec it adds up to a lot of memory. That means a lot of time spent in the GC, which means a lot of GC pauses, not to mention effects on memory bandwidth, locality, and processor cache usage. All else equal, using less memory is faster and more scalable than using more memory. Java programmers seem to frequently forget that object references do have a cost associated with them. Tangentially, those complex object graphs also make (de-)serialization much harder than it needs to be. Requests & responses should be as simple as possible!

gmarx 10y ago
What did it save you server-wise and how long did it take to identify and make the change? Also, did you discover this as part of a performance problem investigation or was it something you saw upfront and nipped in the bud before it became a problem. I agree it sounds like poor design. I instinctively simplify whatever info is going to be sent from the server.
- breischl 10y ago
  It was something written by a different team, so it was committed by the time I saw it. But I thought it looked bad immediately. Profiling later showed that it was a problem spot, and changing it showed decent improvement.
- x0x0 10y ago
  Generally when building servers on top of a jvm, it's a good idea to be able to capture eg 1m requests, replay them, and monitor your memory allocation / gc as part of quality tests. If you create nests of objects in java, it quickly gets expensive, both in terms of net memory and gc costs. One common place this happens is parsing json/xml; use thrift or protobufs instead. If you are eg building an ad server that is supposed to sustain some XX thousand requests per second, you want to also monitor eg eden, survivor, tenured, and promotions. Bump pointer allocation and gc is very fast -- normally faster even than manual memory management -- as long as almost nothing survives. The problem is if some objects start accidentally living past requests, stuff goes boom fast.

gmarx 10y ago

What did it save you server-wise and how long did it take to identify and make the change? Also, did you discover this as part of a performance problem investigation or was it something you saw upfront and nipped in the bud before it became a problem. I agree it sounds like poor design. I instinctively simplify whatever info is going to be sent from the server.

breischl 10y ago
It was something written by a different team, so it was committed by the time I saw it. But I thought it looked bad immediately. Profiling later showed that it was a problem spot, and changing it showed decent improvement.
x0x0 10y ago
Generally when building servers on top of a jvm, it's a good idea to be able to capture eg 1m requests, replay them, and monitor your memory allocation / gc as part of quality tests. If you create nests of objects in java, it quickly gets expensive, both in terms of net memory and gc costs. One common place this happens is parsing json/xml; use thrift or protobufs instead. If you are eg building an ad server that is supposed to sustain some XX thousand requests per second, you want to also monitor eg eden, survivor, tenured, and promotions. Bump pointer allocation and gc is very fast -- normally faster even than manual memory management -- as long as almost nothing survives. The problem is if some objects start accidentally living past requests, stuff goes boom fast.