Dan Shumow <danshu@xxxxxxxxxxxxx> writes: > At this point, I would suggest that I take the C optimizations, > clean them up and fold them in with the diet changes Linus has > suggested. The slowdown is still 2x over block-sha1 and more over > OpenSSL. But it is better than nothing. And then if there is > interest Marc and I can investigate other processor specific > optimizations like ASM or SIMD and circle back with those > performance optimizations at a later date. > > Also, to Johannes Schindelin's point: >> My concern is about that unexpected turn "oh, let's just switch >> to C99 because, well, because my compiler canehandle it, and >> everybody else should just switch tn a modern compiler". That >> really sounded careless. > > While it will probably be a pain, if it is a requirement, we can > modify the code to move away from any c99 specific stuff we have > in here, if it makes adopting the code more palatable for Git. I was assuming that we would treat your code just like how we treat any other "borrowed code from elsewhere". The usual way for us to do so is to take code that was released by the "upstream" (under a license that allows us to use it---yours is MIT, which does) in the style and language of upstream's choice, and then we in the Git development community takes responsiblity for massaging the code to match our style, for trimming what we won't use and for doing any other customization to fit our needs. As you and Marc seemed to be still working on speeding up, such a customization work to fully adjust your code to our codebase was premature, so I tentatively queued what we saw on the list as-is on our 'pu' branch so that people can have a reference point. Which unfortunately solicited a premature reaction by Johannes. Please do not worry too much about the comment. But if you are willing to help us by getting involved in the "customization" part, too, that would be a very welcome news to us. In that case, "welcome to the Git development community" ;-) So,... from my point of view, we are OK either way. It is OK if you are a third-party upstream that is not particularly interested in Git project's specific requirement. We surely would be happier if you and Marc, the upstream authors of the code in question, also act as participants in the Git development community. Either way, thanks for your great help.