build: Optimization of the final executable file size

[Shonke]

The current compiled executable file size is 1.5GB. Is it possible for its size to become smaller? Using dynamic loading? Or can manual trimming be allowed during build?
file download from https://github.com/risingwavelabs/risingwave/releases

[lmatz]

Hi @Shonke,
are you looking to deploy RW in certain resource-constraint environments?

[Shonke]

Hi @Shonke, are you looking to deploy RW in certain resource-constraint environments?

Yes, I think it is. So could this possibly appear in the plan?

[lmatz]

do you mind sharing more details about the environment?

[Shonke]

do you mind sharing more details about the environment?

I manage a cluster with 16 nodes (4c8g) and approximately over a hundred pods. I want to try RisingWave, considering that if production deployment requires multiple nodes, it would be great if it could save some resources.

[BugenZhao]

I have also opened an issue for this: #15150

[Shonke]

@BugenZhao Hey, you can try this out. After using strip processing, its size became 390M, and I'm not sure why they included debug information in the release, which is strange.

[BugenZhao]

@BugenZhao Hey, you can try this out. After using strip processing, its size became 390M, and I'm not sure why they included debug information in the release, which is strange.

Thanks. We decided to adopt "full" debug information to maintain the debugger experience, even in production. This allowed us to analyze core dumps and identify issues, typically memory unsafety due to malfunctioning FFI dependencies or unsafe code.

We expected split-debuginfo to achieve an optimal balance between binary size and observability. Ideally, the binary should be small and only contain necessary information like line tables for backtraces, and the rest of the debug info should all lie in the separate .dwp file, which is not distributed to user by default.

However, things seem not to work as expected. To maintain the ability to link the separate .dwp file, some overhead is introduced into the binary. Consequently, the binary is not small. There are also some discussions about this in the community:

• https://users.rust-lang.org/t/split-debug-info-sizes-doesnt-make-sense/104785
• https://users.rust-lang.org/t/how-to-gdb-with-split-debug-files/102989
• https://stackoverflow.com/questions/75415840/rust-split-debuginfo-binary-is-still-large
• Are dwp files the right choice for split-debuginfo=packed on Linux? rust-lang/rust#105991

It appears that the best approach for now is still to manually split the artifact into binary & debug info files with strip. I'll do some further investigations later to confirm if it really helps.