Michel Daviot

[Bench.txt](https://github.com/skjolber/3d-bin-container-packing/files/8919260/Bench.txt) It's completely anonymous, here is the code. Basically : 3 similar containers are defined. Each of the 3 bench tries to pack a set of boxes in the containers....

OK, even without the rotations, the performance is still up to 90% worse with 2.X :s

> that result was for the fast brute force packager right? The plain / LAFF 2.x should be sufficiently fast. Actually my use case is to provide an API to...

It works fine ! I finally upgraded in production to 2.1.0 and the metrics seem good latency is similar  (one the spike due to JVM warmup is passed) -...

Some more insights after the night  - We are still spending more time than before in LAFF - With the new version, most of the time seems to be...

Yesterday I had to rollback to using 1.X in production, too many requests are not respecting the timeout. I think this is mostly related to #533

I did a bench comparison between 1.X and 2.X (latest) - 1.X racing BruteForcePackager and LargestAreaFitFirstPackager (all rotations of container) - 2X racing FastBruteForcePackager, FastLargestAreaFitFirstPackager and LargestAreaFitFirstPackager (no rotations) all...

Hmm writing in issues is a bit like talking to a nice 🐥 :D I changed the implementation to race FastBruteForcePackager, FastLargestAreaFitFirstPackager(rotations) ``` packerBench22Packets avgt 3 1.749 ± 1.922 ms/op...

after 30 minutes in production with this implementation `race FastBruteForcePackager, FastLargestAreaFitFirstPackager(rotations)` , the latency is similar to 1.X and CPU usage seems fine too 

that would be great ! I'm glad we have (hopefully) succeeded to upgrade to 2.X so we can benefit from such improvements