You still have to watch how many objects you create. This article looks at a benchmark passing events over TCP/IP at 4 billion events per minute using the net.openhft.chronicle.wire.channel package in Chronicle Wire and why we still avoid object allocations.. One of the key optimisations is creating almost no garbage. Allocation is a very cheap operation and collection of very short-lived objects is also very cheap. Does this really make a difference? What difference does one small object per event (44 bytes) make to the performance in a throughput test where GC pauses are amortised? While allocation is as efficient as possible, it doesn’t avoid the memory pressure on the L1/L2 caches of your CPUs and when many cores are busy, they are contending for memory in the shared L3 cache. Results Benchmark on a Ryzen 5950X with Ubuntu 22.10. JVM Vendor, Version No objects Throughput, Average Latency* One object per event Throughput, Average Latency* Azul Zulu 1.8.0_322 60.6 M event/s, 528
It depends on the context and what your customer expects. I will differentiate between 3 type of editions:ReplyDelete
1. the ones that can be solved by the customer, like a NumberFormatException from a customer data.
2. The ones that customer cannot do anything like a NullPointerException.
3. Others we can retry, like the dependency is not available.
So for 3 I will not show them to customer unless they are persistent, in which case they become exceptions of type 2.
For type 1 you need to show to the customer and I will not log anything, obviously you need to catch it.
For type 2 you should show to customer as well and potentially with a way to report the error.
Is this blog dead? no posts since Mar.2017ReplyDelete
Please follow the links to my new blog, though the last post was the end of May, I have more posts planned.Delete