Re: native compilation units

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]

On Sat, Jun 4, 2022, 1:57 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Lynn Winebarger <owinebar@gmail.com>
> > 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

[-- Attachment #2: Type: text/html, Size: 6498 bytes --]