Killing atom's performances in a specific case

pelallemant commented 6 years ago

Hi,

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:
- Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
- Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
- Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
- Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
- Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

When I work with projects, I usually have 1 .git folder, in which I may have 2 or 3 main folders. I use 1 atom window per folder. In this case, when this extension is enabled, the 1st window becomes horribly slow.

Steps to Reproduce

Have a project git in a folder I will name root with 2 folders, root/folder1 and root/folder2.
cd root/folder1 && atom . -> you can use it, atom is normal
cd root/folder2 && atom . -> if the other atom window is still opened, she became horribly slow.
Your window root/folder2 must have 0 files opened, in order that this plugin show the messages.

Expected behavior: [What you expect to happen]

Atom shouldn't be slown.

Actual behavior: [What actually happens]

Atom first window is slown at a point that it is not usable.

Reproduces how often: [What percentage of the time does it reproduce?]

100%.

If I disable this package, I do not have any problem. If i re-enable it, I do have those problems.

Versions

Atom    : 1.23.3
Electron: 1.6.15
Chrome  : 56.0.2924.87
Node    : 7.4.0

Additional Information

The project on which I do have there problems has about 450 PHP files (45M) in the root/folder1, and the 2nd folder is a Symfony3 application with easily 100-200 php classes. The .git repository's size is 46Mo. The bug may happen when each folder has enough files.

I restarted from an empty .atom, disabled all the core packages, and re-enabled then 1 per 1 in order to figure out which package cause the bug. This is systematic, each time the package is re-enabled, window root/folder1 is slown down alot, and when disabled, atom is super-fast as it should always be.

It doesn't affect only file edition, when in the settings view, the scroll is 'blocked' during 2-3 secs each 7-8 secs. I had the same kind of lags when the window state of my atom was corrupted.

winstliu commented 6 years ago

@ungb @Ben3eeE can you try to reproduce this? I tried briefly but couldn't.

ungb commented 6 years ago

I wasn't able to repro the issue either. I tried it on mac.

What behavior are you seeing that is slow?

Is there any content in either folders or they are both empty?

I ran the following and didn't see any slowness

mkdir root
mkdir root/folder1
mkdir root/folder2
cd root
git init
cd folder1 && atom .
cd ../folder2 && atom .

pelallemant commented 6 years ago

I updated my post, and re-shared a demo video of the bug occured, on atom/atom's slack (since I can't upload mp4 files here).

winstliu commented 6 years ago

I've published a new version that stops background-tips from displaying if the window isn't focused. That seems like it might help in this case.

simurai commented 6 years ago

Only somewhat related: When trying out sticky root projects I noticed a lag in scrolling performance, but with further testing, it seems to be related to the background tips animating at the same time.

Since performance in Atom is quite critical, I wonder if the background tips should be static? Like just have a few tips rendered once when opened, and not keep switching them forever. I'll see if I can propose a new design. There is also an opportunity to add some buttons like open/add project/file or so.

atom / background-tips