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

High package activation time #306

Closed
borishere opened this issue May 16, 2017 · 5 comments
Closed

High package activation time #306

borishere opened this issue May 16, 2017 · 5 comments
Labels

Comments

@borishere
Copy link

Hi, sometimes I get high activation time as on screenshot. Is it expected or?

image

@borishere
Copy link
Author

In fact, when I launch Atom, I can work in it only after ~50 seconds (Atom is hanging).
Without 'pigments' package Atom is ready for work after ~7 seconds.

@Cxarli
Copy link
Collaborator

Cxarli commented May 20, 2017

Could you please share your Atom version with us? If it is 1.18-beta, #308 could be an issue here.

@borishere
Copy link
Author

borishere commented May 29, 2017

@C-Bouthoorn I use 1.18.0-beta2.
I discovered that scanning for variables aka color palette causes this hanging. May be the reason is a lot of color variables in my project. Seems that nothing can help me until I disable searching for variables :(

@abe33
Copy link
Owner

abe33 commented Jul 27, 2017

Actually it probably might not be the scanning itself that takes time, as it's an async operation, but rather the deserialization of previously discovered variables. Because scanning a whole project directory takes time and resources the package is using the state serialization mechanism Atom provides to store these variables between sessions, but now it's the serialization/deserialization that become the bottleneck as it's a synchronous operation (I guess they're just JSON.stringify & JSON.parse the whole thing).
I don't really have a plan to rewrite that part to use a different strategy as it'll imply a lot of new issue to tackle. Without knowledge of how is structured it's hard for me to give you a workaround, but generally, if if the project is really huge, with a lot of dependencies, there might be a lot of variables that doesn't come directly from your code but are found in dependencies, and in that case it sometime make sense to excludes these dependencies from pigments' paths to reduce the burden on state serialization.

@Cxarli
Copy link
Collaborator

Cxarli commented Sep 22, 2017

Closing in favour of the master post.

@Cxarli Cxarli closed this as completed Sep 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants