6 ms·

I don't know if I've ever seen a java application where performance is so maxed out that this was needed. Not to say that they don't exist, just that it seems l

• chrisseaton 7y ago
  The thing with cache is that it's a performance cliff. The binary difference between stalling and not stalling can be massive. What looks like a tiny pedantic change can take you across that boundary and help you make efficient use of hardware resources and electrical power.
• suresk 7y ago
  A lot of the more obscure settings are things you don't need to even know about 99% of the time, but it sure is nice to have them when you need them. Just last week, I was helping with some performance tuning on an application that needs to match some set of criteria against tens of thousands of rules, and needs to do so in around 30ms under fairly constant load. Hitting our latency/throughput targets required a lot of tuning, especially around GC. Among other things, it was important to make sure most/all of a request could be handled in the TLAB. I could definitely see something like this giving us a few more milliseconds per request, and I'm definitely going to try it out in a next round of performance work - always nice to have a bit of head room.
• jdmichal 7y ago
  Any Java code that is that tight would probably be looking at eliminating allocations, not making them faster. Allocations mean new memory addresses, new cache lines. If you reuse the same objects for the next operation, they're already allocated and maybe even still in cache. And since Java touches all the memory on object creation anyway, resetting the object isn't too burdensome.
  • deleted 7y ago
    [deleted]