Reduce the weight of the produced binary for faster start time

[SoapyDev]

Optimise for weight at the expense of compile time, speed and we strip debuging elements

Pull Request

Title

Reduce binary weight to reduce waiting time for slower connection.

Type of Change

• New feature
• Bug fix
• Documentation Update
• Refactoring
• Hotfix
• Security patch
• UI/UX improvement

Description

Indicate to the compiler to :

• Optimise for weight rather than speed
• Take more time to improve linking at compile time
• Remove debug info (is already the default on release)
• Compile using only 1 code gen unit (longer compile time in exchange for better optimisation)
• To abort when under panic (reduce code generation, and so far the unwinding with Ratatui is horrible)
• Strip any symbols from the binary. (An other option is strip = "debuginfo" if we don't want to go that far)
• Incremental build turned to off (in our case this should not have any effect, but there is cases where loses of performance where noted)

Testing

Yes

Impact

Reduce the binary size from 2.2 MB to 1.1 MB, so around 50% reduced weight with no human noticeable impact to performance.

Issue related to PR

• Resolves Takes a long time to run the command. #170

Additional Information

Those improvement are stable. There is also unstable improvements that can be added.
Lets also note that we could also create a slim release rather than making this the default. Unsure if there would be any real benefits to be found.

For more information:
https://doc.rust-lang.org/rustc/codegen-options/index.html

Checklist

• My code adheres to the coding and style guidelines of the project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no errors/warnings/merge conflicts.

[afonsofrancof]

I still think it's very weird for the user of #170's pc to take 10 seconds for two simple curl commands.
The current binary size is already pretty small, and if it takes him 10 seconds to start linutil, then the commands that will run inside it will take many minutes. If the user only wants to run commands that don't require more downloads, for example the display, Bluetooth and Wi-Fi control tools, then it makes more sense.

I think we should prioritize performance until the binary size gets too big.

[SoapyDev]

I agree that it's strange.

On the other hand, I do think that its well established that Linux breath a second life in older hardware, so many users might still be using an old, dare I say, ancient machine.

For new comers in the Linux world, I think its a risk free entry to dust off an old laptop and test it out there.

So, in that regard, I think we could address this right now.
Never the less, I agree that the opt-level could be switched back to the default value. Its the only one making runtime trade-offs between size and performance. The rest is more about compile time trade-offs and direct removal of elements in the binary.

Keeping the opt-level as default still return a 1.3 MB file

Original : 2.2 MB
Size opt : 1.1 MB
Size opt with default opt level : 1.3 MB

[afonsofrancof]

I think it makes sense for users to install Linutil if they want to use it for offline commands.
Could you check #180 and give your feedback there?

[Kingproone]

Since I'm not entirely sure what causes the lengthy launchtime for me, can you guys recommend some tests i could run, or any ideas to help better this? Also, could you share how long it takes for the command to run as well (for some sort of a baseline)?

[SoapyDev]

Since I'm not entirely sure what causes the lengthy launchtime for me, can you guys recommend some tests i could run, or any ideas to help better this? Also, could you share how long it takes for the command to run as well (for some sort of a baseline)?

@Kingproone, I can think of a few things that might affect the result that you can test.

• Are you using Wifi or are you plugged in (Wifi 3-6 can be very unreliable) ?
• Can you share the spec of the machine (CPU, RAM, Ethernet card, HDD or SSD or NVME) ?
• Do you have access to another machine on the same network to see if you get the same result (if you do, then we know its not machine dependant)?
• After a reboot, wait a hot minute, what is your baseline for the machine for it's CPU, RAM, DISK, NETWORK (trying to see if your machine is already heavily taxed).
• Does time of the day affect results (this can be the case for some providers that allocate resource to a block of houses)?
• If you Download the source code and execute the binary directly, is it taking a lot of time before you get a visual response (this would indicate that download and size are not the cause)?

Those are not really proper tests, but it can give pointers to where the issue(s) might lay in your case.

[Kingproone]

I redid the test, with version 08.20 as of now, and based on them I would have to assume that it may have been a time of day issue (based on past experiences, unlikely) and/or something with v 08.01.

Regardless of that, optimizing the package size outweighs speed, since computing power is generally more abundant than available internet speeds.

1 The original system

-using ethernet, installed on ssd(sata)
-since the last test i updated the system for latest packages

2 Laptop

- using wifi(4), installed on a 5200rpm hdd, endeavouros
- this one is way slower than my desktop, so it should not have been a hardware specific issue
- this one has not been updated in a few months, showing the utility runs fine on outdated systems