On Thu, Mar 14, 2013 at 4:23 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi kusma,
>
> On Thu, 14 Mar 2013, Erik Faye-Lund wrote:
>
>> Since ancient times, we have been calling curl_global_init with the
>> CURL_GLOBAL_ALL-flag, which initializes SSL (and the Win32 socket
>> stack on Windows).
>>
>> Initializing SSL takes quite some time on Windows, so let's avoid
>> doing it when it's not needed.
>>
>> timing of echo "" | ./git-remote-http.exe origin http://localhost
>>
>> before
>>
>> best of 10 runs:
>> real    0m1.634s
>> user    0m0.015s
>> sys     0m0.000s
>>
>> worst of 10 runs:
>> real    0m2.701s
>> user    0m0.000s
>> sys     0m0.000s
>>
>> after
>>
>> best of 10 runs:
>> real    0m0.018s
>> user    0m0.000s
>> sys     0m0.000s
>>
>> worst of 10 runs:
>> real    0m0.024s
>> user    0m0.000s
>> sys     0m0.015s
>
> Good analysis!
>
>> diff --git a/http.c b/http.c
>> index 3b312a8..528a736 100644
>> --- a/http.c
>> +++ b/http.c
>> @@ -343,7 +343,8 @@ void http_init(struct remote *remote, const char *url, 
>> int proactive_auth)
>>
>>       git_config(http_options, NULL);
>>
>> -     curl_global_init(CURL_GLOBAL_ALL);
>> +     curl_global_init(CURL_GLOBAL_WIN32 | (prefixcmp(url, "https:") ? 0 :
>> +         CURL_GLOBAL_SSL));
>>
>>       http_proactive_auth = proactive_auth;
>
> I wonder whether we want to have something like this instead:
>
>         flags = CURL_GLOBAL_ALL;
>         if (prefixcmp(url, "https:"))
>                 flags &= ^CURL_GLOBAL_SSL;
>         curl_global_init(flags);
>
> I do see that CURL_GLOBAL_ALL is #define'd as CURL_GLOBAL_WIN32 |
> CURL_GLOBAL_SSL in curl.h, but that might change in the future, no?
>

Good suggestion. But perhaps we'd want to use CURL_GLOBAL_DEFAULT
instead? I'm thinking that this define is probably what they'd include
any essential flags, but not non-essential flags. CURL_GLOBAL_ALL
might be extended to include initialization bits for other transports,
for instance... but this feels a bit hand-wavy. Simply masking out the
CURL_GLOBAL_SSL-flag would probably be the smallest logical change.

I don't have any strong feeling on this, really. I'd like to hear what
other people think, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to