AI has improved over the last 6 months, with quality in the mid-range. It takes less effort to get it to produce a mediocre-to-average-quality solution. In many cases, this is good enough. For production, while we still need a rewrite, there is less effort required to prototype it first.
This post explores using AI as a mock User, something AI is particularly suited for.
- AI remembers nothing from previous tests by default.
- It has a broad knowledge set
- It reads most of the documentation
In this post I look at a simple event to response latency benchmark, MarketDataSnapshot to NewOrderSingle at 50K/s for 30 minutes using JLBH to test Chronicle-FIX. The goal is to compare a system which is doing redundant work (in this case logging each message using SLF4J), compared with not logging (Chronicle-FIX records every message internally using Chronicle Queue) and how this changes the choice of Garbage Collector
Most Iterators should be placed on the stack anyway. If they are not and you have a random access collection like ArrayList you can use an index, but this is rarely needed.
If you are going to change code, perhaps Stream(s) are a better choice, these are also placed on the stack most of the time.
Reusing your objects can be confusing for other developers. You need to be careful with anything exposed via an API, however internally you can me more optimised.
In each case the default settings were used (i.e. no options were provided). In both Java 8 (Parallel GC) and Java 11+ (G1), As the GC was a small portion of the time, changing the GC wasn't expected to make a difference anyway.
The GC isn't involved with allocation, the expensive bit here. The GC handles the clean up.
The allocations create memory pressure that can easily saturate the bus to DDR if you are not careful.
This is where using a profiler like YourKit or Flight Recorder is your friend. It will show you the objects that can't be optimised away and where code bottlenecks are. It's hard to determine this in advance for Java.
Something not generally mentioned is that Java can inline what would be virtual methods in C++, it can also remove them as behaviour changes or code is unloaded.