-
Notifications
You must be signed in to change notification settings - Fork 68
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
Comments
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. |
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 " UPDATE: My system is Solus Linux, pigments v0.40.2, Atom v1.22 x64. Look at the timeline between 10000ms and 11500ms. |
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 |
The lag is happening within a 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 |
This part of the Node.js 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.
|
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 :( |
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" |
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
orhighlight-css-color
might. A (prehistoric) version of pigments, known asatom-color-highlight
is still downloadable too. No guarantees are given for any of them to work.The text was updated successfully, but these errors were encountered: