From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Sun, 5 Jun 2022 09:53:50 -0400 Message-ID: References: <834k11d96h.fsf@gnu.org> <83sfolas30.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000246d0405e0b3b074" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1378"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 05 16:03:14 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nxqqX-0000EC-RR for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jun 2022 16:03:13 +0200 Original-Received: from localhost ([::1]:41516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxqqW-0005lS-Ho for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jun 2022 10:03:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57062) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxqht-0000z7-QV for emacs-devel@gnu.org; Sun, 05 Jun 2022 09:54:17 -0400 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:41904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxqhn-0006Ha-OV; Sun, 05 Jun 2022 09:54:17 -0400 Original-Received: by mail-lj1-x233.google.com with SMTP id 1so13219748ljp.8; Sun, 05 Jun 2022 06:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5CDEbtNfM1kV8fs3usIXl506sbsC1snPpGbE5K3+K8s=; b=N41CG/IIr4PSTaXCJcR337wFROUVhmwoXfnWKMQH5fxPS6lcMtM/t67OGJImbOzqix WitBXo1Jo+F1VoxUF8b97m3lyMk+V3UEKCezhnTcgOUOaXBWQ7S/MUPrJO2TKFgsYvP5 Sm41Yfq88Hjne0fqXI4AHL3nqsVC/dMuZzOjtxwyxdoKk7XBua/Jpyxq5cVzhDIXJtxM FFySzYjpJK56ZJVZEtM5m/xPHSrvWmDAQlQPz1lGNq740+NHGEUNCTRBGwkjAe27YmXN zbSxbkRXXJuI5vVy/DDTVoNlQr32rBwIExoJdEA7fFA+AQtXqGOAr5CDjjFHh9jFCXW2 b9Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5CDEbtNfM1kV8fs3usIXl506sbsC1snPpGbE5K3+K8s=; b=QEyF7meVYMLuCVGnsqNyuxn7hCNrCVh05lTHxkHjzQa6WmfRcA6tmZ01ozNCQCKKu5 EwpkGCLwIJXH35KBEU+KI364NjuIP5cNKVjOiM8oIqXYAkSCYDDI149OXylMlyXpteaD p1daVo6uP+1RzSwB+s5JyJ4S1vrAdMwfOHPxanxEWm9e7U0BG7TYtex5MRdv9O4BJ3Ng rx+nmEmGd553dyrqTR6riPEZkK7WL8ZRhvRjVv/KaJJ1xZGqcpOj6tcUufVDzRD/6DIq dWin4/racmjd+Ltf/zO6+P3X3ts5wxfHWp+KrOeozztjXvjXO6tmgH3yo+qyTYst6BP5 GYHg== X-Gm-Message-State: AOAM533TLfD9SQdVcqQlVmR6QecFXjM+ubFTH31pxmCi+gQX/qsdiX9D x2/by4K4LRXmonPEcdBRL2B2OgUmx/H3Bhxdp9OMk3sFZXc= X-Google-Smtp-Source: ABdhPJx0t0rcl3kae/hHyD1kA8O82MEh3VNm0EDvAX621QuXlSnz1bFBl0PaLkl2QrpXUKLuFCzX5PADrbCsTS8e1wQ= X-Received: by 2002:a2e:86c1:0:b0:255:485d:9a9a with SMTP id n1-20020a2e86c1000000b00255485d9a9amr22934994ljj.129.1654437242497; Sun, 05 Jun 2022 06:54:02 -0700 (PDT) In-Reply-To: <83sfolas30.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=owinebar@gmail.com; helo=mail-lj1-x233.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 05 Jun 2022 10:02:36 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:290711 Archived-At: --000000000000246d0405e0b3b074 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 4, 2022, 1:57 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Fri, 3 Jun 2022 15:17:51 -0400 > > > > Unfortunately most of my "productive" experience in a Windows > environment has been in a corporate > > environment where the configuration is opaque to end users. For all I > know, it's not just a network issue but > > could also involve the security/antivirus infrastructure. > > I can tell you that at approximately 1000 files in a directory, any > process I've designed that uses said > > directory slows down dramatically. Just displaying the contents in file > explorer exhibits quadratic behavior as > > the process appears to start refreshing the listing before completing > one pass. > > You can try setting the w32-get-true-file-attributes variable to the > value 'local. > > Or maybe the following entry from etc/PROBLEMS will help: > > ** A few seconds delay is seen at startup and for many file operations > > This happens when the Net Logon service is enabled. During Emacs > startup, this service issues many DNS requests looking up for the > Windows Domain Controller. When Emacs accesses files on networked > drives, it automatically logs on the user into those drives, which > again causes delays when Net Logon is running. > > The solution seems to be to disable Net Logon with this command typed > at the Windows shell prompt: > > net stop netlogon > > To start the service again, type "net start netlogon". (You can also > stop and start the service from the Computer Management application, > accessible by right-clicking "My Computer" or "Computer", selecting > "Manage", then clicking on "Services".) > I was only intending to illustrate a situation in which a local packager (internal to an organization) might want to (a) provide pre-compiled versions of elisp files that may or may not be from files installed in the "lisp" directory, while (b) not wanting to have huge numbers of files in a particular directory for performance reasons. The performance issues I've experienced are not particular to any individual application, and the way the Windows systems are configured I may not even reliably be able to tell if a given application is stored on a local or network drive (although performance may lead me to believe it is one or the other). They do appear to be particular to the context in which I have been using Windows, though. > As for elpa being created in the user's cache, that depends on whether > the user has access to the gccjit > > infrastructure > > If the user cannot use libgccjit on the user's system, then why *.eln > files from external packages are relevant? They will never appear, > because native compilation is not available. > > So I don't think I understand what you are saying here. > > If you have in mind ELPA packages that come with precompiled *.eln > files (are there packages like that?), then the user can place them in > several directories and adapt native-comp-eln-load-path accordingly. > So again I don't think I understand the problem you describe. > A local packager can precompile anything they like and put it in the system native-lisp directory, no? I'm not sure if the package system would find it if installed as a package by the user, but many packages are just single files that can just be placed directly in site-lisp and used directly. > > this was one of the points mentioned in > > https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html as > it related to the system lisp files. > > Sorry, I don't see anything about the issue of eln-cache location > there. Could you be more specific and point to what was said there > that is relevant to this discussion? > I was thinking of these: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html particularly: I don't understand yet the packaging requirements, is it not possible to copy additionally the native-lisp/ folder to the package? and then these points: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01009.html https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01020.html Lynn --000000000000246d0405e0b3b074 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Jun 4, 2022, 1:57 AM Eli Zaretski= i <eliz@gnu.org> wrote:
> From: Lynn Winebarger <owinebar@gmail.co= m>
> Date: Fri, 3 Jun 2022 15:17:51 -0400
>
> Unfortunately most of my "productive" experience in a Window= s environment has been in a corporate
> environment where the configuration is opaque to end users.=C2=A0 For = all I know, it's not just a network issue but
> could also involve the security/antivirus infrastructure.
> I can tell you that at approximately 1000 files in a directory, any pr= ocess I've designed that uses said
> directory slows down dramatically.=C2=A0 Just displaying the contents = in file explorer exhibits quadratic behavior as
> the process appears to start refreshing the listing before completing = one pass.

You can try setting the w32-get-true-file-attributes variable to the
value 'local.

Or maybe the following entry from etc/PROBLEMS will help:

=C2=A0 ** A few seconds delay is seen at startup and for many file operatio= ns

=C2=A0 This happens when the Net Logon service is enabled.=C2=A0 During Ema= cs
=C2=A0 startup, this service issues many DNS requests looking up for the =C2=A0 Windows Domain Controller.=C2=A0 When Emacs accesses files on networ= ked
=C2=A0 drives, it automatically logs on the user into those drives, which =C2=A0 again causes delays when Net Logon is running.

=C2=A0 The solution seems to be to disable Net Logon with this command type= d
=C2=A0 at the Windows shell prompt:

=C2=A0 =C2=A0 net stop netlogon

=C2=A0 To start the service again, type "net start netlogon".=C2= =A0 (You can also
=C2=A0 stop and start the service from the Computer Management application,=
=C2=A0 accessible by right-clicking "My Computer" or "Comput= er", selecting
=C2=A0 "Manage", then clicking on "Services".)

I was only intending to illustrate a situation = in which a local packager (internal to an organization) might want to (a) p= rovide pre-compiled versions of=C2=A0 elisp files that may or may not be fr= om files installed in the "lisp" directory, while (b) not wanting= to have huge numbers of files in a particular directory for performance re= asons.
The performance issues I've experienced are not partic= ular to any individual application, and the way the Windows systems are con= figured I may not even reliably be able to tell if a given application is s= tored on a local or network drive (although performance may lead me to beli= eve it is one or the other).=C2=A0 They do appear to be particular to the c= ontext in which I have been using Windows, though.

> As for elpa being created in the user's= cache, that depends on whether the user has access to the gccjit
> infrastructure

If the user cannot use libgccjit on the user's system, then why *.eln files from external packages are relevant?=C2=A0 They will never appear, because native compilation is not available.

So I don't think I understand what you are saying here.

If you have in mind ELPA packages that come with precompiled *.eln
files (are there packages like that?), then the user can place them in
several directories and adapt native-comp-eln-load-path accordingly.
So again I don't think I understand the problem you describe.

A local packager can precompile anything they li= ke and put it in the system native-lisp directory, no?
I'm no= t sure if the package system would find it if installed as a package by the= user, but many packages are just single files that can just be placed dire= ctly in site-lisp and used directly.
=C2=A0
> this was one of the points mentioned in
> https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html<= /a> as it related to the system lisp files.

Sorry, I don't see anything about the issue of eln-cache location
there.=C2=A0 Could you be more specific and point to what was said there that is relevant to this discussion?

particularly:
I don't understand yet the packaging requirements, is it=
 not possible to
copy additionally the native-lisp/ folder to the package?
--000000000000246d0405e0b3b074--