From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: builds are getting slower? Date: Wed, 16 Dec 2015 11:50:11 +0000 Message-ID: References: <8337vab7nx.fsf@gnu.org> <0d7fkmdxj1.fsf@fencepost.gnu.org> <566D0BEB.4010707@cs.ucla.edu> <52wpsif21j.fsf@fencepost.gnu.org> <6tpoy9aorv.fsf@fencepost.gnu.org> <83fuz54sfk.fsf@gnu.org> <83d1u73cz8.fsf@gnu.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11410b903cbc0b0527028239 X-Trace: ger.gmane.org 1450266660 11766 80.91.229.3 (16 Dec 2015 11:51:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Dec 2015 11:51:00 +0000 (UTC) Cc: Glenn Morris , eggert@cs.ucla.edu, emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 16 12:50:55 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a9Abd-00024R-W2 for ged-emacs-devel@m.gmane.org; Wed, 16 Dec 2015 12:50:54 +0100 Original-Received: from localhost ([::1]:46784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Abd-0005ny-CQ for ged-emacs-devel@m.gmane.org; Wed, 16 Dec 2015 06:50:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Ab3-0005hx-0C for emacs-devel@gnu.org; Wed, 16 Dec 2015 06:50:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9Ab1-0006wq-W9 for emacs-devel@gnu.org; Wed, 16 Dec 2015 06:50:16 -0500 Original-Received: from mail-lf0-x229.google.com ([2a00:1450:4010:c07::229]:36029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Aay-0006w5-Va; Wed, 16 Dec 2015 06:50:13 -0500 Original-Received: by mail-lf0-x229.google.com with SMTP id z124so22477587lfa.3; Wed, 16 Dec 2015 03:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1azjrP9gpoF/bRFji1s6+05FWvZdoAbbA7egSpylAv4=; b=tJoNSQ/bc7I9d7rAz3J0nyDrCm4oxfWG1GewJNxTvedCZGq8Ury3QTaumFlkr/uv++ N1WymUxanE0ajpd/1dGy4ErZHTNf9xA7+V6SWnQOZXPZcg1o15UwSKS8/Bob1jiFKyGR YwBQdWbkyrI+vrXY1jDi9iY7Ldp0E2bSrV7y2ge7OYo/nFnvc18+q4bfNhTrQHVt1aE9 p6GfYKXwPWJp9X0tqd9a9Sg9nYO9mvpKf9TmwoV2sIKAAvxClh/QQq6iEBHrryiYLS38 kTuC0ztkufkfd9oz6Wnt13Opoq38bl2vgO8UTSRRv9Oncdkx2J/9ywucsAoxq7Ah1QPa Pawg== X-Received: by 10.25.211.209 with SMTP id k200mr18095345lfg.125.1450266611987; Wed, 16 Dec 2015 03:50:11 -0800 (PST) Original-Received: by 10.112.202.99 with HTTP; Wed, 16 Dec 2015 03:50:11 -0800 (PST) Original-Received: by 10.112.202.99 with HTTP; Wed, 16 Dec 2015 03:50:11 -0800 (PST) In-Reply-To: <83d1u73cz8.fsf@gnu.org> X-Google-Sender-Auth: 0wTJAASeJ7uK0lh6BoQD2QgiZ7Q X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196364 Archived-At: --001a11410b903cbc0b0527028239 Content-Type: text/plain; charset=UTF-8 On 15 Dec 2015 4:15 pm, "Eli Zaretskii" wrote: > > Maybe I'm reading the code wrongly, but it looks like even before the > cache could kick in, dir-locals-find-file calls > locate-dominating-file, passing it dir-locals--all-files as its > predicate. This has 2 effects: (a) it loads "seq", and (b) it calls > file-expand-wildcards, which needs to read the entire directory and > then match each file against a regexp. > > Could these be the cause of slowdown? Probably. And no, You're not reading it wrong. We need to locate the dir locals file(s) in order to compare its timestamp to the cache. Do we have a faster way of expanding wildcards? Maybe it would be faster to not allow wildcards at all, and just have a fixed regexp that we use in directory-files. If that doesn't help, then we could also forgo of the regexp, and just have two allowed filenames (like .dir-locals.el and .dir-locals-2.el). --001a11410b903cbc0b0527028239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 15 Dec 2015 4:15 pm, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> Maybe I'm reading the code wrongly, but it looks like even before = the
> cache could kick in, dir-locals-find-file calls
> locate-dominating-file, passing it dir-locals--all-files as its
> predicate.=C2=A0 This has 2 effects: (a) it loads "seq", and= (b) it calls
> file-expand-wildcards, which needs to read the entire directory and > then match each file against a regexp.
>
> Could these be the cause of slowdown?

Probably. And no, You're not reading it wrong.
We need to locate the dir locals file(s) in order to compare its timestamp = to the cache. Do we have a faster way of expanding wildcards?

Maybe it would be faster to not allow wildcards at all, and = just have a fixed regexp that we use in directory-files.

If that doesn't help, then we could also forgo of the re= gexp, and just have two allowed filenames (like .dir-locals.el and .dir-loc= als-2.el).

--001a11410b903cbc0b0527028239--