git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jeff King <peff@peff.net>,
	git@vger.kernel.org, Jeff Hostetler <jeffhost@microsoft.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] mingw: use OpenSSL's SHA-1 routines
Date: Mon, 13 Feb 2017 18:46:35 +0100	[thread overview]
Message-ID: <9913e513-553e-eba6-e81a-9c21030dd767@kdbg.org> (raw)
In-Reply-To: <20170210160458.pcp7mupdz24m6cms@sigill.intra.peff.net>

Am 10.02.2017 um 17:04 schrieb Jeff King:
> On Fri, Feb 10, 2017 at 04:49:02PM +0100, Johannes Schindelin wrote:
>
>>> I think this is only half the story. A heavy-sha1 workload is faster,
>>> which is good. But one of the original reasons to prefer blk-sha1 (at
>>> least on Linux) is that resolving libcrypto.so symbols takes a
>>> non-trivial amount of time. I just timed it again, and it seems to be
>>> consistently 1ms slower to run "git rev-parse --git-dir" on my machine
>>> (from the top-level of a repo).
>>>
>>> 1ms is mostly irrelevant, but it adds up on scripted workloads that
>>> start a lot of git processes.
>>
>> You know my answer to that. If scripting slows things down, we should
>> avoid it in production code. As it is, scripting slows us down. Therefore
>> I work slowly but steadily to get rid of scripting where it hurts most.
>
> Well, yes. My question is more "what does it look like on normal Git
> workloads?". Are you trading off an optimization for your giant 450MB
> index workload (which _also_ could be fixed by trying do the slow
> operation less, rather than micro-optimizing it) in a way that hurts
> people working with more normal sized repos?
>
> For instance, "make BLK_SHA1=Yes test" is measurably faster for me than
> "make BLK_SHA1= test".

The patch does add a new runtime dependency on libcrypto.dll in my 
environment. I would be surprised if it does not also with your modern 
build tools.

I haven't had time to compare test suite runtimes.

> I'm open to the argument that it doesn't matter in practice for normal
> git users. But it's not _just_ scripting. It depends on the user's
> pattern of invoking git commands (and how expensive the symbol
> resolution is on their system).

It can be argued that in normal interactive use, it is hard to notice 
that another DLL is loaded. Don't forget, though, that on Windows it is 
not only the pure time to resolve the entry points, but also that 
typically virus scanners inspect every executable file that is loaded, 
which adds another share of time.

I'll use the patch for daily work for a while to see whether it hurts.

-- Hannes


  reply	other threads:[~2017-02-13 17:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 22:27 [PATCH] mingw: use OpenSSL's SHA-1 routines Johannes Schindelin
2017-02-09 23:41 ` Junio C Hamano
2017-02-11  8:01   ` Johannes Sixt
2017-02-11 18:51     ` Junio C Hamano
2017-02-13 17:16     ` Johannes Schindelin
2017-02-16 18:12       ` Johannes Sixt
2017-02-10  5:02 ` Jeff King
2017-02-10 15:49   ` Johannes Schindelin
2017-02-10 16:04     ` Jeff King
2017-02-13 17:46       ` Johannes Sixt [this message]
2017-02-13 19:42         ` Junio C Hamano
2017-02-13 21:07           ` Johannes Sixt
2017-02-13 22:38             ` Johannes Schindelin
2017-02-14  6:14               ` Johannes Sixt
2017-02-24 21:54         ` Junio C Hamano
2017-03-02  6:07           ` Johannes Sixt
2017-03-02 17:07             ` Junio C Hamano
2017-02-25  0:44   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9913e513-553e-eba6-e81a-9c21030dd767@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jeffhost@microsoft.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).