Sure. Bumping.

• http://ghcr.io/fierycod/holy-lambda-builder:aarch64-java17-22.1.0 • http://ghcr.io/fierycod/holy-lambda-builder:aarch64-java11-22.1.0 • http://ghcr.io/fierycod/holy-lambda-builder:amd64-java11-22.1.0 • http://ghcr.io/fierycod/holy-lambda-builder:amd64-java17-22.1.0

Fantastic - thank you

@karol.wojcik I’ve tried one of my functions with the new image (`aarch64-java17-22.1.0`). Highlights: • bb hl:native:conf && bb hl:native:executable worked without modification to build args, only necessary change was to bb.edn was to update :image • build time down quite a lot - 22.0 took 89s vs 71s in 22.1, approx 20% improvement! 😄 • however, the .holy-lambda/build/latest.zip size was up by ~730k (approx 3%)

Have you tried Java11?

It should be at least 5MB smaller.

nope

why it that?

GraalVM includes includes more classes for Java17 as far as I remember.

Worth trying.

trying it now

in my case the image size did decrease a little, but not by 5MiB: 17: 25618644 11: 25204244

Yeah. This is only 400KB

Build time was 76s.

worth a try through.

I’ll take the build time improvement though. My HL Lambda count is now at 31.

Impressive! 🎉

Btw there is a development mode for building images now.

Have you tried it?

not yet - will be looking at it this week

On the GraalVM unboxing stream, they referred to UPX for reducing binary size. Have you come across it? https://youtu.be/eE1Gghkfi-M?t=728

Yep. I’m planning to add this option for babashka. I would rather not use upx for native image. AFAIK the startup performance would be nightmare.

Makes sense

Especially for small memory configurations where the allocated CPU is proportional to memory. The decompression would likely be quite slow in that case.

Right. Anyway could you please share some feedback HL bb tasks? Anything that you feel should be improved?

Generally, the tasks work well and I really like the separation between HL and SAM now. That said, a few suggestions: I noticed in the past, particularly when refactoring code or changing dependencies (e.g. change logging implementation) that references to old libs remained somewhere. Consequently, I always build bb hl:clean && bb hl:compile && bb hl:native:executable That might be a bit of an overkill, so maybe something in compile could more precisely clear existing assets before compilation thus ensuring the “purity” of the build? I also had similar issues with hl:native:conf. When changing deps or refactoring, I now also have to rm -rf resources/native-configuration before running conf. Might be useful to always do this as part of conf? Localisation is baked into HL and it forces US locale. Presumably, this is to optimise the image size. I was caught out by this last year and it was only through noticing command line output from HL that I saw the locale options. I can explicitly supply the native image args but I would like to see this made more explicit in bb.edn so that it’s more apparent that the locale is fixed. With hl:native:conf there are a couple of other things: I have to run hl:compile before hl:native:conf or I receive a stale code warning. However, hl:native:conf seems to build the code anyway. hl:native:conf seems to apply the contents of resources/native-agents-payloads and agent/in-context functions twice. Is that really necessary? Control of the graal’s new quick build might be best served using a command line param rather than feeding in args via bb.edn When official M1 support for GraalVM arrives (support in 22.1 is only a preview), I wonder if it is faster to build the executable outside of docker?

zip -9 improves compression for latest.zip. as-is: 25621061 zip -9 : 25297902 improvement of 323k

@karol.wojcik ^^ was this the sort of thing you were after?

Oh yeah @U01RXDR9F4M! This helps a lot!! I'm planning to rewrite CLI once again, cause it has some rough edges. I now know what the users expect from the CLI, so expect in a few weeks a RFC document with the design of CLI. Your feedback is extremely valuable to me 🙂

count me in for any reviews and I’ll do what I can to help