Native compilation vs virus scanners

Here's a pitfall for the --with-native-compilation option which I'd not previously considered... My work changed its anti-virus software, and my native-comp Emacs init time increased from ~2 seconds to ~15 seconds (and more like 20 before it's usable), because the libraries are now all native code and the virus-scanner goes to work on every one of them. Subsequent starts were fast (2-3 seconds) while the scanner had things cached, but later on they will be slow again. If you mostly only run Emacs once per session, that's probably not an issue; otherwise it's another thing to consider. If you're using a native-comp build and loading libraries seems slow, this is a potential reason for that.

My init time is 60 seconds 😐

That is truly impressive.

Since you offered... how? Are you running Doom inside Spacemacs or something?

Isn't this what the daemon is for?

As surprising as it may be, different people have different needs, and some of us start Emacs instances at other times (with configs that *usually* load quickly enough to not be a bother). Your suggestion *will* be sufficient for some, but then I already said that: > If you mostly only run Emacs once per session, that's probably not an issue

You [low rider](https://www.youtube.com/watch?v=r-punsKBd94)

Startup time largely depends on your storage performance. My config started in 6 seconds on native Linux on SSD, 20 seconds on WSL 1 on SSD, and 360 seconds on WSL 1 on HDD!

Not at all. An emacs daemon makes creating a new emacs window much faster whereas native compilation makes the resulting code run much quicker.

Why not both.

Right, I never considered use cases where you may need to reload the daemon, just the frame. Could you use a tool to [preload](https://wiki.archlinux.org/title/Preload) into RAM?

Mine used to be about 15 seconds. I wanted to improve that, so I switched to straight.el and use-package.el to do as much delayed loading as possible, now my emacs startup time is 2 seconds with a few dozen packages.

That link seems like it's just a form of disk caching, so it wouldn't have any effect on the problem I described. The Emacs build process facilitates pre-dumped configurations, so I imagine I'd do that if I was going to jump through any hoops to avoid the problem. Personally I'm happy sticking with the byte-code interpreter (native-compilation hasn't provided any obvious benefits with my config), but I figured others would find the issue interesting.

Preload isn't quite the same as disk caching. It's basically RAM caching during startup, so your load times would be much faster. Makes sense to revert in your situation though.

yes

You really don't need a virus scanner in 2022 outside of windows defender, and nothing on linux. Just don't download anything shady.

> My **work** changed its anti-virus software [emphasis mine]

Ah, didn't catch that bit.

Here's a fun read: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html

Poor advice. Define "shady". It's like saying avoid the bullets and you'll be fine.

That’s still pretty long? I have 63 packages I’m pulling from Melpa, and a trickle of my own custom config. On wsl2 and SSD, it still starts in sub second. On my 2018 MacBook Pro, it took 1.29 seconds on my last try. Note: I use straight.el to defer loading many packages until I really need to. For example, I use a bunch of packages related to org, which don't load at startup. They're set to load when I open an org file or switch to org-mode. Edit: I meant use-package 😅

Is a standard VM like VirtualBox an option? That would skip the AV while being in a confined environment.

I feel you pain! My work has been using McAffe for a while now, and it probably has to be the most developer hostile applikation out there. It make my init time incredible long, takes up 40-60% from time to time, make Magit almost unbearably slow, slows down all file-IO and on top of that it blocks internet access in WSL2 so running Emacs there (or doing anything basically) is out of the question. Now we it looks like we are going over to Microsoft Defender so I have hopes that it will get better after that, but as all things corporate, it takes a long time.

To be fair Emacs has the potential to be a huge security breach, with users downloading and running code from all over the internet and no sandboxing worth mentioning. The only reason it is not one is that the market share is low, and that the code of all packages is public. So even if almost nobody checks all the code they install, someone would probably notice malicious code in one of the popular packages. For your problem, there could be different answers. The most natural one would be to ask IT to whitelist the folder with your native-compiled binaries, but for the above reason I'd understand if IT said no. > Subsequent starts were fast (2-3 seconds) while the scanner had things cached, but later on they will be slow again. Caching should be a sane answer to the problem. Do you know why it gets slower again? Does the cache get invalidated for some reason? Or does the scanner itself erase its cache after some time? Maybe this is something IT would be willing to address.

The second part is not very helpful, but the first part is sane. Most of the antivirus/antimalware work is done by the OS and the webbrowsers nowadays. And there were reports about 10 years ago (maybe the situation changed) that adding an antivirus on top of that was actually harmful, because the antivirus would prevent the browsers from implementing some low-level sandboxing techniques.

my init time is pretty low (about 1sec), but I use daemon anyway

> native compilation makes the resulting code run much quicker. depends on packages you use, for some configuration there's little or no difference at all

straight doesn't defer loading of packages. It installs, builds, and activates packages. Perhaps you meant use-package?

Yep you’re right! Thanks for correction! They’re tied so closely for me I frequently mix them up.

The smallest difference I've found is still about twice as fast. What are you using that isn't faster? I'd like to dive into it and see why and see if it can be made faster. Which benchmarking are you using?

> Which benchmarking are you using? I'm skeptical that he's done any actual measurements.

For my part I've done no benchmarking, but I've *observed* no obvious performance benefits at run-time in my actual day-to-day use. What I *have* observed is plenty of system slow-downs whenever native-compilation is happening (and now also at load times). I'm sure the code is running faster in a strict sense; but when the slow downs are significantly more apparent than the speed-ups, the feature feels like a net-loss. I'll also add that, when the two things are not inextricably linked, how fast an interactive application *feels* is usually more important than how fast it actually is, so far as user satisfaction is concerned. So I agree with the "for some configuration there's little or no difference at all" statement, and would also extend it further to say that in some cases the *overall* performance may seem better with only the byte-compiler. (None of which is to suggest that the feature isn't very worthwhile for other people with different configs or systems.)