Fork me on GitHub
Chris Lowe15:04:39

@karol.wojcik GraalVM 22.1 CE is out today - is there any chance of upping the docker images?

Karol Wójcik15:04:55

Sure. Bumping.

🙌 1
Chris Lowe15:04:06

Fantastic - thank you

😄 1
Chris Lowe16:04:34

@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/ size was up by ~730k (approx 3%)

Karol Wójcik16:04:25

Have you tried Java11?

Karol Wójcik16:04:32

It should be at least 5MB smaller.

Chris Lowe16:04:40

why it that?

Karol Wójcik16:04:49

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

Chris Lowe16:04:03

trying it now

Chris Lowe16:04:10

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

Karol Wójcik16:04:51

Yeah. This is only 400KB

Chris Lowe16:04:19

Build time was 76s.

Chris Lowe16:04:09

worth a try through.

Chris Lowe16:04:59

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

Karol Wójcik17:04:34

Impressive! 🎉

Karol Wójcik18:04:17

Btw there is a development mode for building images now.

Karol Wójcik18:04:32

Have you tried it?

Chris Lowe18:04:30

not yet - will be looking at it this week

Chris Lowe06:04:25

On the GraalVM unboxing stream, they referred to UPX for reducing binary size. Have you come across it?

Karol Wójcik06:04:47

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.

Chris Lowe07:04:17

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

Karol Wójcik07:04:18

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

Chris Lowe08:04:42

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?

Chris Lowe10:04:29

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

Chris Lowe10:05:59

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

Karol Wójcik13:05:02

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 🙂

Chris Lowe13:05:09

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

❤️ 1