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:
ReplyDelete1. 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.
ReplyDeleteI saw lot of information On Other Site But this blog helped me alot to learn Java Thanks for sharing.........
Is this blog dead? no posts since Mar.2017
ReplyDeletePlease follow the links to my new blog, though the last post was the end of May, I have more posts planned.
Delete