[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: native compilation units

From: Lynn Winebarger
Subject: Re: native compilation units
Date: Sun, 5 Jun 2022 09:53:50 -0400

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:
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:




reply via email to

[Prev in Thread] Current Thread [Next in Thread]