Closed SoapyDev closed 1 week ago
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.
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
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?
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)?
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.
Those are not really proper tests, but it can give pointers to where the issue(s) might lay in your case.
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.
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
Description
Indicate to the compiler to :
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
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