zamazan4ik/answer_to_burntsushi_1.md

## answer_to_burntsushi_1.md

      
    Raw
  

              answer_to_burntsushi_1.md
            
          
I was specifically talking about ripgrep though. And I found your comment pretty condescending personally, since it implied I wasn't considering user experience.

I didn't want to attack you personally or anything like that. I meant only that "release-lto" is less visible to users by default, and it creates more complexity in discovering this profile. I never meant that you don't care at all about users -  of course I understand that by separation of these profiles you care about "Ripgrep installation UX" experience from the "waiting for finished build" way, and I appreciate that! Possibly my words sounded a bit too rude - I sincerely apologize for that. I didn't mean anything like that. And I want to point this straight - I highly appreciate your work in many fields, especially for "ripgrep" as my daily driver. I am trying my best in using right and polite words since English isn't my native language. I do not want to offend anyone and my intention is keeping the conversation exclusively in a polite way  with arguments. I believe in such opinion exchange like our this dialogue more insights can be uncovered (at least for me). I hope my apologize will be accepted.

This is absurd. cargo build defaults to opt-level=0 precisely because the tooling cares about runtime perf vs installation time.

By "Installation time UX" I meant "cargo install", which uses the Release profile, not "cargo build" during the local iteration process. I am totally happy with current "cargo build" defaults regarding the Dev profile - it's right choice (and possibility to have partial optimization to some dependencies is a great part too).

Also an absurd conclusion to draw. cargo binstall isn't maintained by the Rust project, so it definitely wouldn't be promoted as the default. Distributing binaries in general is way way way more complicated than that, and there's way more at play here than just whether the Rust project "cares" about the runtime vs installation time trade-off. Schlepping binaries off of GitHub works fine for an unofficial project, but that wouldn't fly as something officially endorsed by the Rust Project.

I agree with you that specifically "cargo binstall" shouldn't be promoted for exactly this unofficial reason. I chose "cargo binstall" only because it's the most viable Cargo-native way to actually save build resources on a user machine. All possible issues about trust to this tool, binary verifiability, etc. are fully reasonable, and I would never argue with that. If "cargo binstall" or any similar alternative will go under the Rust Foundation umbrella (please don't be too strict here - I don't know the exact Rust official team layout, orgs, etc.) or any other "official" form - of course this and only this should be promoted by Rust. I don't any other way besides using external package manager (but this of course another story with its own well-known issues). Or we can say that Rust dev team doesn't care at all about building Rust-based apps on potatos - in that case we can simply ignore that "binary caching" problem and just enable more aggressive stuff (but seems like we care right now).
Do I understand that the Rust team has limited resources and probably there are another important issues in the Rust ecosystem? Of course I understand that. But that doesn't mean for me that I need to do nothing. I use Rust tools a lot right now, and it's true for a lot of other people in the world. And I see that  many people are more than okay with changing current defaults in one way or another to bring at least smaller binaries for the ecosystem. Not because C or C++ fanatics are tend to troll Rust for large binaries by default (and even don't try to run "min-sized-rust") but because proposed by me changes bring measurable improvements and are consistent with many existing guidelines in the ecosystem.

But you're switching from an is to an ought! We were talking about whether it makes sense, today, to enable fat LTO. But now you're talking about what the ecosystem should be moving towards. That's a totally different question and not one that I opined on at all. (Because I don't really disagree. I just think it's a Very Hard problem to solve.)

I agree with you that this problem is hard to solve but I believe that this problem at least worth looking into it (or at least considering) by the Rust development team.
My LTO issue "template" has changed several times during my work with adding CU1 into the "optimization" bundle, reporting actual build time changes at least on one computer (my). I do not hide anything from a project author/maintainer: I just show them raw numbers before/after in binary size and clean build time + references into the corresponding Cargo documentation parts. The final decision is always done by the upstream. And my issues show that a lot of people are happy with applying these changes - I guess I can safely say more than half (formal statistics is not gathered yet). Not all of them, of course, and probably number one reason is the "cargo install" time - only project author can make a final decision here.
My point is if so many users are happy with applying proposed by me LTO (in most cases Full) and CU=1 and they haven't done it before my report - maybe we need to improve something by default? At least consider this option more seriously once again and think about it. Maybe some official Rust poll can be created here, maybe something else - I do not know but I am ready to give my opinion. By my work I just trying to highlight - the issue exist, and in many cases project authors want more for their apps even in the default Release profile.
Do I understand that changing default Release profile is too hard thing? Of course I do. Maybe we need one more official Cargo profile - Distribution, that will enable more aggressive stuff like LTO, CU1, maybe something else, and Cargo will use this profile by default (and users can opt-out to older behaviour). Right now we have "dist" with its "[profile.dist]" defaults - but it needs to be integrated separately by authors (they don't do it since people don't know about it / it requires some efforts to enable, etc.). And even for the Dist profile people are okay with enabling FullLTO instead of Thin in many cases.
Why do I suggest in all my issues putting FullLTO into the Release profile? Because right now it's the most guaranteed way to deliver improvement (more optimizations) to the end-user.
Do I think that my "manual reporting approach" is the right way? Of course it isn't - it's one of the most dumb manual work that can be done. Ideally, I do not want to do it - I want all that thing done for me by Cargo. But current situation is that this way it's the most straightforward way to deliver more optimized binaries to users. My way is not scalable, it's not a right way at all, it's simply stupid - but that's what we have right now. And I believe that this is the issue for Rust as for the ecosystem that aims to deliver performance by default. We can and we should do something better.
Some time ago I pushed some "LTO by default" changes in some quite huge part of the Rust ecosystem - Ratatui. Such recommendations can be found in two other important parts of the Rust ecosystem: Tauri and Dioxus . With Ratatui I even achieved more and integrated the recommended flags into the default templates. What I've seen after some time that new Ratatui projects are released with these recommended options, and I didn't see reverts of these recommendations (maybe there are some of them - I just don't know about any). If such parts of the ecosystem are providing the same Cargo recommendations and they are approved by their main developers, maybe we need to think about it more on the Cargo level itself? If we cannot change it on the Cargo level for some reason (I am not a part of the Cargo dev team), what we can do instead for improving current situation? What we can do for finishing my "LTO/CU1 crusade" (except banning me on GitHub - but I will create a twink anyway)? Because current approaches like having awesome "min-sized-rust"-like helpers doesn't work well enough.
Probably it was a bit too much context, but anyway. Let's return a bit back to your comments.

But this "let's surmise what people care about based on a narrow view of outcomes" is nonsense and it's condescending.

I just show that my suggestions is widely accepted by many project authors. I would never say that all people would be happy with such changes - it will never be true (as I am not happy right now with Cargo Release defaults but they are the defaults).
We can ask instead the actual people, including this subreddit, why did many of them (I want to highlight once again - not all!) accept my issues and PRs? Why Ratatui, Tauri and Dioxus recommend similar things? Why even "dist" has some more aggressive defaults compared to provided by Cargo?

We were talking about whether it makes sense, today, to enable fat LTO.

Yep. My data points show that a lot of people are okay with enabling FullLTO even in Release mode that directly affect compilation time on a target user machine with "cargo install". My point of view is that project author is main representative of its users (let's say "Product owner") who knows their audience, there regular concerns and tradeoffs. Completely as you do with "ripgrep" and caring about build time more by default for users than about delivering a bit more performance and/or smaller binary to them. This choice can be done only by you, and you are right in any decision, that you've made in your project. I want to highlight that I've seen several times when project authors declined my proposal - it's especially true for large Rust projects. In such cases, they usually are happy with ThinLTO approach instead - exactly the purpose of the ThinLTO.
I hope I didn't miss any important point from your comments and would be happy to hear your opinion (or anyone else).
No results found