Takes a long time to run the command.

[Kingproone]

Describe the bug

It can take upwards of 10 seconds for me to run the command.

To Reproduce

run the following command and hit Q as soon as it reaches the tui: $ time curl -fsSL https://christitus.com/linux | sh

Expected behavior

Faster launchtimes.

Screenshots

Additional context

• EndeavourOS
• Download speeds for me are ~11 MB/s
• Linutil 08.01
• Ran the command a few times to see variance.

[SoapyDev]

I will address mainly how we can improve the weight of the binary, as it's to my knowledge the only thing we can affect when it comes to GitHub and distribution of the solution.

So far, I can only see 3 improvement that can be done, but they come at a cost or are not in line with the current vision of Chris.

---

1) Optimise the release profile for weight rather than speed.

From my test, we can go from a binary of 2.2 MB to 1.1 MB, so about a 50% reduction in weight. I would expect a non-linear reduction in download time.

Ofc, we lose in performance, but so far even in debug mode, the TUI is really responsive.

I will submit the ticket for that one, as the cost in responsiveness is transparent to the user so far and this is really easy to implement and revert.

---

2) Extract the commands from the binary and download them as needed.

That one, I am less a fan of as we are still in the process of finding a groove for how commands are shown/called and we are displacing waiting time in the preparation stage for waiting time at runtime.

Plus the additional complexity of dealing with async calls and executing the scripts that would add to the weight of the binary. So maybe not a real reduction in weight for now.

But, as the number of commands grow, it might become a needed solution at some point.

---

3) Caching the binary

That one is straight out not aligned with Chris's vision so far. So, I can't imagine this being implemented in the near future. But I still wanted to put it out there, as caching is a solution for users repeating the process of calling the solution.

[jeevithakannan2]

@SoapyDev Reducing the binary size from 2.2 MB to 1.1 MB will not have any effect because as per @Kingproone , the average download speed is 11 MB/s so 2.2 MB binary should not be an issue here. I think it maybe a network latency due to geographical reasons. The more robust solution would be caching the binary by installing linutil. In upcoming days if its planned to install linutil then we should consider reducing the binary size. As of now i think it is unnecessary. Maybe we can set the roots now so that it would easier in the future to manage the binary size.

[SoapyDev]

@jeevithakannan2, I agree. But as stated in #178, the only trade-off being done is at compile time, as the opt-level is set to 3 to maintain performance. That way we still get reduced weight (1.3 MB) for the same performance. It might not fix this issue, but I don't see any reason to not move forward with it.

[jeevithakannan2]

Yeah I agree with you