Hi Dragan,
On Wed, Jan 10, 2024 at 9:39 PM Dragan Simic <dsimic@xxxxxxxxxxx> wrote:
>
> On 2024-01-11 01:33, Elijah Newren wrote:
> > On Wed, Jan 10, 2024 at 1:57 PM Dragan Simic <dsimic@xxxxxxxxxxx>
> > wrote:
> >>
> >> Thus, Git should probably follow the same approach of not converting
> >> the
> >> already existing code
> >
> > I disagree with this. I saw significant performance improvements
> > through converting some existing Git code to Rust. Granted, it was
> > only a small amount of code, but the performance benefits I saw
> > suggested we'd see more by also doing similar conversions elsewhere.
> > (Note that I kept the old C code and then conditionally compiled
> > either Rust or C versions of what I was converting.)
>
> Well, it's also possible that improving the old C code could also result
> in some performance improvements. Thus, quite frankly, I don't see that
> as a valid argument to rewrite some existing C code in Rust.
Yes, and I've made many performance improvements in the C code in git.
Sometimes I make some of the code 5% or 20% faster. Sometimes 1-3
orders of magnitude faster. Once over 60 orders of magnitude
faster.[1] Look around in git's history; I've done a fair amount of
performance stuff.
And I'm specifically arguing that I feel limited in some of the
performance work that can be done by remaining in C. Part of my
reason for interest in Rust is exactly because I think it can help us
improve performance in ways that are far more difficult to achieve in
C. And this isn't just guesswork, I've done some trials with it.
Further, I even took the time to document some of these reasons
elsewhere in this thread[2]. Arguing that some performance
improvements can be done in C is thus entirely missing the point.
If you want to dismiss the performance angle of argument for Rust, you
should take the time to address the actual reasons raised for why it
could make it easier to improve performance relative to continuing in
C.
Also, as a heads up since you seem to be relatively new to the list:
your position will probably carry more weight with others if you take
the time to understand, acknowledge, and/or address counterpoints of
the other party. It is certainly fine to simply express some concerns
without doing so (Randall and Patrick did a good job of this in this
thread), but when you simply assert that the benefits others point out
simply don't exist (e.g. your "Quite frankly, that would _only_
complicate things and cause fragmentation." (emphasis added) from your
first email in this thread[3], and which this latest email of yours
somewhat looks like as well), others may well start applying a
discount to any positions you state. Granted, it's totally up to you,
but I'm just giving a hint about how I think you might be able to be
more persuasive.
Hope that helps,
Elijah
[1] A couple examples: 6a5fb966720 ("Change default merge backend from
recursive to ort", 2021-08-04) and 8d92fb29270 ("dir: replace
exponential algorithm with a linear one", 2020-04-01)
[2] Footnote 6 of
https://lore.kernel.org/git/CABPp-BFOmwV-xBtjvtenb6RFz9wx2VWVpTeho0k=D8wsCCVwqQ@xxxxxxxxxxxxxx/
[3] https://lore.kernel.org/git/b2651b38a4f7edaf1c5ffee72af00e46@xxxxxxxxxxx/
