Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MASTER POST] Pigments slow, unresponding, lagging, blocking, causing Atom to lag, high activation time, insane memory usage #351

Open
C-Bouthoorn opened this issue Sep 22, 2017 · 13 comments
Labels

Comments

@C-Bouthoorn
Copy link
Collaborator

@C-Bouthoorn C-Bouthoorn commented Sep 22, 2017

This has been a long standing issue, and still is. There are multiple issues on Github regarding this problem, and most of them boil down to the same thing: Pigments is slow. We are aware of this problem, and we are sorry.

To clear things up a bit, I decided to bundle links to all issues into one master post. One issue might contain more information than another, so I've tried to sort them by amount of messages and "usefulness".

#125 (38, cpu timeline, dummy file, insights)
#363 (5, script to trigger issue)
#275 (22, insight: might be related to Anti-Virus)
#116 (6, cpu timeline, insights)
#366 (1, only occurs on some markers)
#188 (19, cpu timeline)
#330 (16, commands, stack trace)
#308 (14, stack trace)
#175 (20, dummy project)
#43 (16, dummy file)
#95 (5, dummy file)

Mostly "me too", "same", +1, 👍, confirmations:
#293 (9)
#121 (6)
#340 (5)
#306 (5)
#202 (4)
#235 (2)
#159 (2)
#360 (1)
#367 (1)
#421 (3)

I'd like to ask you all to post any more future information here, to keep it somewhat manageable. Thanks.

Sidenote

As some of you might have noticed, @abe33 seems to be focused on another project. Because of that, maintenance on pigments is slowed down (update: has been brought to a stop).
In the meantime, I'm trying to keep the issues clear, the labels accurate, and to solve small issues. I don't think I'm able to solve this (major) issue on my own, that's why I'm trying to make it easier for others to help.

General recommendations

If the latest version doesn't work, you could try downgrading pigments by uninstalling it, and reinstalling a specific version via apm:

apm install "pigments@0.38.0"

If pigments still doesn't work for you, color-picker or highlight-css-color might. A (prehistoric) version of pigments, known as atom-color-highlight is still downloadable too. No guarantees are given for any of them to work.

@refactorized

This comment has been minimized.

Copy link

@refactorized refactorized commented Sep 26, 2017

Mean time suggestion - is there a way to predict which files will cause issues and just bail on those? This would ideally be user enabled/configured. I think it would be a far better solution than just not using pigments.

I had some luck with ignoring certain types of files ( like large library css files ), but that's not really a solution.

@C-Bouthoorn

This comment has been minimized.

Copy link
Collaborator Author

@C-Bouthoorn C-Bouthoorn commented Sep 29, 2017

@refactorized

As far as I figured it, it seems to happen on big (100+ files) projects. Ignoring minimised versions (.min.css) seems to have helped some. I can't seem to reproduce any of them myself, which makes this a bit hard to dive into.

@mikael1000

This comment has been minimized.

Copy link

@mikael1000 mikael1000 commented Nov 8, 2017

I mostly used Atom for small projects when for example trying out css-animations, js-stuff. I used 2-3 files. I never had lagging in Atom. But today I tried to use it with Laravel and Atom is lagging and the fan is on high speed. Trial en error led me to the conclusion that it is Pigments package that is the problem.

The thing is that Atom is lagging with some other packages too. Sublime is running flawlessly and my computer is pretty good. I think I give up on Atom and just use it for test-of-smaller things.

However I liked pigments and want to thank for it. Thanks!

@ronanharris09

This comment has been minimized.

Copy link

@ronanharris09 ronanharris09 commented Nov 17, 2017

About "pigments.delayBeforeScan", What if the default value changed to manual refresh instead, I mean no auto-scan or refresh on time-counter by default. It hurts my memory usage by hundreds of MB's, even when there's only 4 css files to scan.

UPDATE: My system is Solus Linux, pigments v0.40.2, Atom v1.22 x64.

Look at the timeline between 10000ms and 11500ms.
TimelineRawData-20171117T230434.zip

screenshot from 2017-11-17 23-00-05

@rbaugh

This comment has been minimized.

Copy link

@rbaugh rbaugh commented Dec 29, 2017

I have also had an issue similar to #366. When having the marker type set to native-dot, it causes lags as if the app had crashed. Setting it back to native-background brings it back to life.

Atom: 1.23.1 x64
Pigments: 0.40.2
OS: MacOS 10.13.2

@C-Bouthoorn C-Bouthoorn changed the title [MASTER POST] Pigments slow, unresponding, lagging, blocking, causing Atom to lag, high activation time [MASTER POST] Pigments slow, unresponding, lagging, blocking, causing Atom to lag, high activation time, insane memory usage May 28, 2018
@paradox460

This comment has been minimized.

Copy link

@paradox460 paradox460 commented Jul 17, 2018

Not sure if this is any use to anyone else, but switching to native-background as the marker type gave me a dramatic speed increase. Its not as fast as without the plugin installed, but it's still fast enough to be usable

@forusak

This comment has been minimized.

Copy link

@forusak forusak commented Oct 20, 2018

Why is this still issue? Marker type dot and square-dot is basically useless, and those are exactly types of the marker which I was looking for.

@C-Bouthoorn

This comment has been minimized.

Copy link
Collaborator Author

@C-Bouthoorn C-Bouthoorn commented Oct 22, 2018

@forusak Because the original creator of this repo has given up on it, and no-one has taken the effort of trying to fix it. Please read the full issue and the README file.

@sompylasar

This comment has been minimized.

Copy link

@sompylasar sompylasar commented Jan 15, 2019

According to the profiler:
screen shot 2019-01-15 at 9 59 53 am

The lag is happening within a spawn via Task (it's quite surprising that pigments spawns a separate process).

Below is the code that happens to be slow:

    ColorBuffer.prototype.scanBufferForColors = function(options) {
      var buffer, collection, config, ref1, ref2, ref3, ref4, ref5, registry, results, taskPath, variables;
      if (options == null) {
        options = {};
      }
      if (this.destroyed) {
        return Promise.reject("This ColorBuffer is already destroyed");
      }
      if (Color == null) {
        Color = require('./color');
      }
      results = [];
      taskPath = require.resolve('./tasks/scan-buffer-colors-handler');
      buffer = this.editor.getBuffer();
      registry = this.project.getColorExpressionsRegistry().serialize();
      if (options.variables != null) {
        if (VariablesCollection == null) {
          VariablesCollection = require('./variables-collection');
        }
        collection = new VariablesCollection();
        collection.addMany(options.variables);
        options.variables = collection;
      }
      variables = this.isVariablesSource() ? ((ref2 = (ref3 = options.variables) != null ? ref3.getVariables() : void 0) != null ? ref2 : []).concat((ref1 = this.project.getVariables()) != null ? ref1 : []) : (ref4 = (ref5 = options.variables) != null ? ref5.getVariables() : void 0) != null ? ref4 : [];
      delete registry.expressions['pigments:variables'];
      delete registry.regexpString;
      config = {
        buffer: this.editor.getText(),
        bufferPath: this.getPath(),
        scope: this.getScope(),
        variables: variables,
        colorVariables: variables.filter(function(v) {
          return v.isColor;
        }),
        registry: registry
      };
      return new Promise((function(_this) {
        return function(resolve, reject) {
          _this.task = Task.once(taskPath, config, function() {
            _this.task = null;
            return resolve(results);
          });
          return _this.task.on('scan-buffer:colors-found', function(colors) {
            return results = results.concat(colors.map(function(res) {
              res.color = new Color(res.color);
              res.bufferRange = Range.fromObject([buffer.positionForCharacterIndex(res.range[0]), buffer.positionForCharacterIndex(res.range[1])]);
              return res;
            }));
          });
        };
      })(this));
    };

Looks like the slowest part there is serializing and passing data to the spawned process, especially the buffer: this.editor.getText(), which may be quite large (about 20KB in my case).

@sompylasar

This comment has been minimized.

Copy link

@sompylasar sompylasar commented Jan 15, 2019

This part of the Node.js ChildProcess seems to run the slowest when called from scanBufferForColors (this is the native code process spawn operation):

var err = this._handle.spawn(options);
@borzaka

This comment has been minimized.

Copy link

@borzaka borzaka commented Apr 8, 2019

I have opened a new related issue: #421, but I will share my new findings here as well:

I have a problem with pigments package. Editor is not responding with pigments package installed.

  • alternative package: highlight-colors
  • installing a previous version (0.40.1) doesn't freeze - so probably you can use as well without any problems;
    apm install "pigments@0.40.1"
    (Tested on the latest Atom 1.35.1 x64 Windows 10)
@imaspeer

This comment has been minimized.

Copy link

@imaspeer imaspeer commented Jul 1, 2019

Does crashing the whole desktop counts?

Being slow is one thing, and crashing the editor would already be pretty bad, but this is unacceptable. Though I'd tend to consider this to also be atom's responsibility as the host program, there shoud be checks and limits in place so that if the plugin has to crash, at the very least it doesn't take everything down with it.

@dagfinnur

This comment has been minimized.

Copy link

@dagfinnur dagfinnur commented Nov 10, 2019

Does crashing the whole desktop counts?

Being slow is one thing, and crashing the editor would already be pretty bad, but this is unacceptable. Though I'd tend to consider this to also be atom's responsibility as the host program, there shoud be checks and limits in place so that if the plugin has to crash, at the very least it doesn't take everything down with it.

It crashed my desktop just now. After the restart, I opened Atom again which lead to another crash. So I removed the package from my .atom folder. All my work in Atom is still there but I lost tons of written work in other applications :(
I completely agree with you, this is frustrating and very bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.