From our (fairly unscientific admittedly 😉) experiments we see that it's significantly faster to startup from cold than the official one you might see. And it's not just the embedded Jackson initialisation that's bloating out the standard release - both in terms of size and launch speed - memory is hazy but pretty sure that I also saw log4j in there as well when I was investigating which didn't help. The custom adapter layer for the AWS events that we have built into the http4k runtime is based on Moshi, so that's much smaller/faster as well as there is no reflection at all required.
There is definitely an experiment to be done to compare all these things - I have a half finished repo where we compare across AWS/http4k/Graal runtimes, various serverless implementations for http4k, spring, micronaut, quarkus, and AWS SDK vs http4k-connect. Snapstart will make yet another variant to all this to compare - or just might make the entire comparison moot! 😂
There's also a trade off between lambda-size, memory,cold start time, build time (aka cycle time), and performance. I think it's all about options TBH and what your use-case is and how that all fits into the cost. As always, YMMV so for us it's all about giving people options!
BTW - the docker images that we have above don't produce an image - they output a self-contained function ZIP file which runs on AmazonLinux2 - if that ends up in a docker image in lambda is unknown to me 🙂 .