We are announcing a new patch release of the Crystal 1.16 series.
This is a companion discussion topic for the original entry at https://crystal-lang.org/2025/04/29/1.16.2-released
This is a companion discussion topic for the original entry at https://crystal-lang.org/2025/04/29/1.16.2-released
8 Likes
Saw recompiling an app with 1.16.2 creates a bigger stripped binary than 1.16.0/1.
With 1.16.0/1: 729,744 bytes
With 1.16.2 : 832,632 bytes
A 102,888 byte difference?
Oh, good catch.
This reproduces even with an empty program:
$ alias drun='docker run --rm -it -v "$(pwd)":/w -w /w'
$ drun crystallang/crystal:1.16.1 crystal build empty.cr -o empty-1.16.1
$ drun crystallang/crystal:1.16.2 crystal build empty.cr -o empty-1.16.2
$ size empty-*
text data bss dec hex filename
1405644 2976 1132960 2541580 26c80c empty-1.16.1
1493381 2976 1132960 2629317 281ec5 empty-1.16.2
I didn’t test it, because I update(compile) crystal from 1.15 to 1.16.3 directly.
Was this fixed in 1.16.3?
No. On my system 1.16.2/3 produce the same size binaries, bigger than 1.16.0/1.
This is not a big deal, (at least for me), as long as more bigger binary size can improve performance.
I tested the latest Crystal release follow following post which wrote by @ralsina
here is some screenshots which we can see some significant performance improvement on pcre2 and the small performance improvement compared to release 9 months ago.
This increase in file size is a consequence of Replace inline type IDs with global constants in LLVM IR by HertzDevil · Pull Request #15485 · crystal-lang/crystal · GitHub
Now we’re embedding the names of all types into the executable as strings, when previously it were only the names of types that were actually instantiated.
Unfortunately, there’s no trivial way to avoid this.
Essentially, we’re trading binary size for compiler performance.
4 Likes
I ran the same benchmark from that post on 1.10 and 1.16.2 and I don’t see any significant changes (less than 1%, which is noise)
I believe the difference is the speedup of the compile process and the compiler itself and not the runtime performance of the compiled executables.
1 Like
