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

Cxarli opened this issue Sep 22, 2017 · 16 comments


Copy link

@Cxarli Cxarli 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.


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.

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.

Copy link
Collaborator Author

@Cxarli Cxarli commented Sep 29, 2017


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.

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!

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.

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

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

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();
        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( {
              res.color = new Color(res.color);
              res.bufferRange = Range.fromObject([buffer.positionForCharacterIndex(res.range[0]), buffer.positionForCharacterIndex(res.range[1])]);
              return res;

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).

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);

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)

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.

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.

Copy link

@Zalkota Zalkota commented Nov 27, 2019

It just crashed my desktop as well. How can I fix this.... Ubuntu 18, 0.38.0, Atom 1.41.0

Copy link

@JustAnother-CodeMonkey JustAnother-CodeMonkey commented Nov 20, 2020

The same here, I use to use the versions before rebrand to pigments and it was working great. Don't know if it's still working in latest atom. Overall the package is great and very useful. Especially the autocomplete and highlight of sass variables. I was just checking the issues in hope there is at least some hacky solution to this problem provided by the community. On other older computers I cannot use the package as it freezes / crashes the whole desktop (if you don't kill it before it does). It's using massive amount of ram, than swap and than all you can do is to force restart. I've tested it on multiple Linux based setups.

The problem is with the indexing of a project, it causes 2 consecutive massive spikes of ram ussage with 100% of cpu usages. Once the indexing is done you can start using it and it works great. The reindexing happnens to every new project / directory. I have a new laptop with i7 and 16gb of ram, pcie ssd and on this machine I'm able to withstand the initial load (but it still freezes the comupter for minute or two). The reindexing also happens if I work on a project for a while (day or two) in another editor (tested with vim/nvim) and than return to atom.

I think the solution could be some limits as was already suggested above. Throttling the indexing could be a nice way to achieve this, if it takes longer, it's acceptable but killing the whole system is not. Or at least there should be some configuration for maximum amount of ram the program can use. If the indexing fails because of that it's okay as long as the user can see some notification about it.

Copy link

@AnotherDevlop AnotherDevlop commented Apr 22, 2021

Possibly of little help, but it spawns hundreds of process on indexing. Some of them gets suspended forever, some get zombified. It should not spawn a indexing process if there is already one. Seems that if the delay before scan is lesser than the time the indexing process lasts (more than a indexing process for the same file at a time), start arising problems.

Workaround is to set "Delay Before Scan" to at least 1 minute (for my use case), or to an actual big time (in order of days) and use command "Pigments: reload"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests