From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Harsanyi Newsgroups: gmane.emacs.devel Subject: Re: vc-dir operation is very slow on large git repositories in Emacs 26.1 Date: Mon, 25 Jun 2018 20:23:46 +0800 Message-ID: References: <83k1qtsbgi.fsf@gnu.org> <83zhzoqkgv.fsf@gnu.org> <83efgzqjv5.fsf@gnu.org> <83wouqptm6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1529929312 32291 195.159.176.226 (25 Jun 2018 12:21:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2018 12:21:52 +0000 (UTC) Cc: Eli Zaretskii , Emacs-Devel To: Bastian Beischer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 14:21:48 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXQV9-0008Iy-G9 for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2018 14:21:47 +0200 Original-Received: from localhost ([::1]:46528 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXQXG-0004w3-Ly for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2018 08:23:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXQX7-0004vw-P7 for emacs-devel@gnu.org; Mon, 25 Jun 2018 08:23:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fXQX7-0007V3-0w for emacs-devel@gnu.org; Mon, 25 Jun 2018 08:23:49 -0400 Original-Received: from mail-io0-x229.google.com ([2607:f8b0:4001:c06::229]:40024) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fXQX5-0007Ub-Dv; Mon, 25 Jun 2018 08:23:47 -0400 Original-Received: by mail-io0-x229.google.com with SMTP id g22-v6so12336376iob.7; Mon, 25 Jun 2018 05:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3VumvewkztLndwSkoamc3zbB9kCXw27DsUXYaw3lCq0=; b=JnXAkIsg8iTdgd+qCT6Ym9o/LxlxODw/3pND3GPHrF66vc5jGG9V+sZ1PoDdGkVq/q 8iYT//rIA3VSc6UYVtsErG2wHA289iAzgqD9bQZMs7O8JwxR92RAlbyXu5wl6CY/zcVP X0lhBJS7ihGqK0nkm/Oj9GnyTrLKkGNA8vYAQ72/HfioQ6s7/Dl8q23td1O40xeOrMvx CqdO8YHNcii9mf2J9nokQE+7FHkKfPnW/e3LPASVANcALwTuIJWE2QsJeKYox/dMpbhQ eO9rUuPiPy/Hj4oho+806LcUI1+0Sx/4g9df0q7nSniSMZ7ufum+G6qbzjArVTjt0J26 Fs8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3VumvewkztLndwSkoamc3zbB9kCXw27DsUXYaw3lCq0=; b=fx13ptT+MGOxywwQM5bVRhiZRzZZUh7GavGeiBHfGjs5tLsfZz0FXblc382eyquw+n Kk0PXywwK/VQpEhUMZpBynqtSQgrLLN6G3AzSbkP8OhKYK+Q0znNKQu5Flz20TkOzho9 a4UroTpj9pSQhfIz7WHgl8tT56hRXggJYa0zPU8XgQP9TvxTVPfC+wpZM29NEq4eiMf+ lonf+1h/mCV7ssrGITz59cWTOIfq/77+Dav5nxP9GoeejfFzLqf5AiLkdhXIGC0x3SSH vFM7FIfqN7Jr1gmhS7l1z+p1JhmJ4En8U2lU8bivM99WQCNWybugelhDuGWyjvD40YYK VzXg== X-Gm-Message-State: APt69E3HFMJ0RWjEGLPRw+hqJGgoH9zPbHXC2j9UaIqSE9ERPfaS7Mus hgjDMUSkWck4v79uXnKe0bYAkkvVc7Hnbxv68jg= X-Google-Smtp-Source: AAOMgpcCEv2aNG4JBxkptw0o3Z3mKOIwfaIbilDwjgSZRND087iXxaNwlGxxle3bGYZ2EbZ5198h51btD/MWJHh4VuU= X-Received: by 2002:a6b:8792:: with SMTP id r18-v6mr1322051ioi.243.1529929426723; Mon, 25 Jun 2018 05:23:46 -0700 (PDT) Original-Received: by 2002:a6b:4514:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 05:23:46 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226701 Archived-At: On Mon, Jun 25, 2018 at 7:09 PM, Bastian Beischer wrote: > Hi, > > On Mon, Jun 25, 2018 at 12:40 PM, Alex Harsanyi wrote: >> So, with a 50 millisecond delay, it takes 83.7 seconds to read the command >> output and this is reduced to 1.07 seconds when the delay is set to 0. > > From these timings it appears that you have been using a 4096 byte > buffer. The logic is as follows: > > Assume that all the delay in the 83.7 seconds is due to 50ms waits, > one such wait whenever the buffer is full. This is based on the fact > that you observe a ~proportional slowdown when increasing the > read-delay. Then this means that the buffer was full 1674 times, which > means that the buffer size is 6.5 MB / 1674 = 4071 - approx. 4096 > bytes. So the predicted approximate delay for a message of size S is > > D = (S / B) * W > > where B is the buffer size (4096) and W is the w32-pipe-read-delay > (0.05 s). Based on that logic it appears that setting > w32-pipe-buffer-size to 16384 should give you a ~four times smaller > total delay - especially when w32-pipe-read-delay is 50 ms, for > example. Unless the OS refuses to provide you with such a buffer size? > Setting w32-pipe-buffer-size has no effect on the timings, see my previous emails about this. I do not know why. Alex.