add 1s to atom launch time

[tonylee2016]

[lierdakil]

Well, it doesn't do this for me, so there's that. For me, Timecop reports 63ms, i.e. 1 second less than for you.

So. Either this is a fluke, which happens with Atom from time to time, or you're on a rather slow system (the most likely culprit here would be slow HDD), but then a few other packages are probably activating forever too, or your particular system configuration just has weird unwanted interactions with something in the package. Either way, I need a lot more details to figure out what's going on and how to fix it.

[tonylee2016]

probably a blip, sometimes it does not happen for me

[aubreyz]

Actually it very consistently takes over a second to load for me -- on a fast system. By a long way the slowest loading of all packages I use. Two consecutive timecop reports below. Not the end of the world as it is a great package, but I do think worth exploring where the bottleneck is. Not sure if it makes a difference what documents are opened during the loading, but I don't think that is what timecop is reporting since the total load time is much longer than the sum of the packages load times. They do swop around a bit though (see below the vastly different loading times of spellcheck much faster the second consecutive time of the day after a re-boot (whereas this package does not).

[lierdakil]

Can't repro:

These numbers are very consistent between restarts.

[lierdakil]

As an experiment, try installing MPP from bundle branch and see if that helps any.

[aubreyz]

I did some debugging a) Package load time of MMP is unrelated to whether there are markdown pages loaded as part of the activation b) However, the long load time is definitely due to scrutiny of the package by the inbuilt Windows Defender. When this is switched off (globally) the load time goes down 10 fold. See screenshots. At some point if I get time I will try to establish which exact file is causing problems.

[lierdakil]

Okay, I'll try to make it easier. Please try installing unreleased MPP version from https://github.com/lierdakil/markdown-preview-plus-alpha. Here's how:

1. Remove currently-installed MPP via apm uninstall markdown-preview-plus, or from Atom GUI.
2. Install the package from git via apm install --production https://github.com/lierdakil/markdown-preview-plus-alpha (don't forget --production otherwise installation will take quite a while)

After you run your tests, you'll probably eventually want to switch to mainline release. Just uninstall and install normally then.

What I did: bundled the distribution into a couple mostly self-contained js files. Note that this has some implications, for instance, can't use cson for macros file no more (switched to yaml instead, which should be mostly compatible, but not quite).

Why this might help: I've speculated that drive access is slow, hence loading modules takes an unreasonable amount of time. Your investigation suggests that it's not that drive access itself is slow, but that drive operations are intercepted by Windows Defender. This doesn't change much in terms of optimization: we want to reduce the number of drive accesses. Bundling is known to help in this case; as an added bonus, installation should also be a little faster.

If it works, cool, I will push out a new major release after I convince myself the drawbacks are worth it. If it doesn't, also cool, I don't have to deal with the drawbacks then.

Since I can't reproduce the issue (I'm not even on Windows), I can't really figure it out without some help.

Thanks in advance.

[aubreyz]

I'll get to your methods above shortly when I get a chance. In the meantime:

It seems out that this is a known problem with Eclipse (See for example this thread https://bugs.eclipse.org/bugs/show_bug.cgi?id=548443) and possibly also in Atom (Windows Defender has at various points in the past also regarded the whole of atom as malware https://github.com/atom/atom/issues/8246).

It obviously influences different packages more than others. Everything in Atom loads a whole lot faster without Defender, as each and every script file is locked as it is loaded, maybe MPP just has a larger number of locks to get through?

It is possible to exclude certain folders from Windows defender (at risk of the user obviously). I wanted to see whether it was just excluding the package files (as opposed to the stuff that loads stuff in the package) improved matters.

You can exclude stuff in defender by 1. Windows 10 settings. 2. Search for "Virus & threat protection" 3. Click on "Manage settings" 4. "Add or remove exclusions" under "Exclusions" section. Exclude folders or files.

I tried first to exclude the whole of .atom from being scanned., This improves loading dramatically for MMP, and for atom in general.

I then tried to exclude only .atom\packages\markdown-preview-plus and the effect (at least for MMP) was similar (i.e a 10 fold faster loading).

Obviously this carries some potential risk which would be down to the user.

[aubreyz]

OK I tried your alpha version and in the process things became even more confusing. Worth documenting here anyway in case it later proves useful:

a) Before installing the alpha I turned off the exclusion on windows defender and the production version rose again from ~100ms to a ~1000ms load time as before (checked 5 times) b) I then renamed my .atom folder to .atom2 and started a new clean .atom c) Since I don't usually use apm I had to install git to allow the apm install of the alpha (this may be important). I also in error forgot your --production flag despite your warning (again that may be relevant to what followed) d) I installed the alpha -- and hey presto (with windows Defender on) the load time of MPP was 99ms e) I then uninstalled the alpha and installed the main MPP which also loaded in 101ms ! f) I then went back to my original .atom and was most surprised to find that MPP in that was now loading at 95ms ! g) I wondered whether my installation of git could somehow be relevant so I uninstalled git but loading time of MPP had remains <0.1sec. Every other package is also loading much faster.

But something in the process of switching defender on and off, switching it to exclude .atom and then reverting that, installing the alpha MPP in a different .atom folder, installing and uninstalling git, and loading atom about 100 times seems to have given things a huge kick in the pants.

I presume @lierdakil that the alpha installation without the --production would only have put stuff in the temporary .atom folder and not in the main atom installation or anywhere else that might have corrected something?

It is also possible that because I loaded atom about 100 times in the process of these tests Windows suddenly learned that it should stop scanning the same stuff over and over again, so it may take some time to get back to its old ways. If that is the case then all these tests will not be of use.

Bottom line: Windows defender is definitely something to do with the problem. But there may be something else more complicated happening too.

[lierdakil]

I presume @lierdakil that the alpha installation without the --production would only have put stuff in the temporary .atom folder and not in the main atom installation or anywhere else that might have corrected something?

The difference between --production and no --production is that the latter also downloads build-time dependencies. Of which there are quite a few in this particular case. Hence, without --production installation takes a while (up to several minutes on slower systems I reckon)

I think this might be some sort of issue with Windows Defender's caching or something like that? I'm purely guessing here, but seems like your file manipulation (moving .atom directory) reset some "did I check that" flag in Windows Defender that was previously stuck for some reason. Nothing else seems especially relevant.

[aubreyz]

One day after the above it was back to 1.1sec load time. And definitely toggling to 0.1sec as Windows Defender is switched on and off. Bottom lines: a) At least on my machines Windows Defender is definitely the cause b) It is not a very big deal but useful to understand c) It affects all packages, but some more than others d) This may be due to the number of files loaded e) It might be possible that reducing the number of loaded files helps, but my experiment along those lines failed because it seemed to intersect with some sort of transient learning by Defender. I'm not going to get a chance to repeat the test in the short term but it does seem sensible to reduce the number of files loaded where that is possible. f) It can be resolved if bothersome by setting defender to ignore the package folder in .atom. I imagine the risk of doing that is low, especially when the package is not updated.

[lierdakil]

I've released the bundled version as v4.0.0. Hopefully this helps with load times at least a little. Please open new issues (possibly linking to this one) if not.

[aubreyz]

Well the difference is dramatic.
Activation time immediately before update to 4.0.0 = 1082ms Activation time immediately after update = 35ms !

The load time of some other packages sped up a lot as well (I guess MMP files and other packages are in a queue waiting to get checked, so other packages are also slowed indirectly). The overall Activation time of atom is 5 fold faster than before.