atom-pigments
atom-pigments copied to clipboard
abe33
[MASTER POST] Pigments slow, unresponding, lagging, blocking, causing Atom to lag, high activation time, insane memory usage
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".
https://github.com/abe33/atom-pigments/issues/125 (38, cpu timeline, dummy file, insights) #363 (5, script to trigger issue) https://github.com/abe33/atom-pigments/issues/275 (22, insight: might be related to Anti-Virus) https://github.com/abe33/atom-pigments/issues/116 (6, cpu timeline, insights) #366 (1, only occurs on some markers) https://github.com/abe33/atom-pigments/issues/188 (19, cpu timeline) https://github.com/abe33/atom-pigments/issues/330 (16, commands, stack trace) https://github.com/abe33/atom-pigments/issues/308 (14, stack trace) https://github.com/abe33/atom-pigments/issues/175 (20, dummy project) https://github.com/abe33/atom-pigments/issues/43 (16, dummy file) https://github.com/abe33/atom-pigments/issues/95 (5, dummy file)
Mostly "me too", "same", +1, :+1:, confirmations: https://github.com/abe33/atom-pigments/issues/293 (9) https://github.com/abe33/atom-pigments/issues/121 (6) https://github.com/abe33/atom-pigments/issues/340 (5) https://github.com/abe33/atom-pigments/issues/306 (5) https://github.com/abe33/atom-pigments/issues/202 (4) https://github.com/abe33/atom-pigments/issues/235 (2) https://github.com/abe33/atom-pigments/issues/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 "[email protected]"
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.
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.
@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.
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!
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
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
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
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.
@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.
According to the profiler:
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).
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);
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 "[email protected]"(Tested on the latest Atom 1.35.1 x64 Windows 10)
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.
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.
It just crashed my desktop as well. How can I fix this.... Ubuntu 18, 0.38.0, Atom 1.41.0
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.
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"
