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

elm-lens has long startup time #22

Open
jhrcek opened this issue Jan 23, 2018 · 4 comments
Open

elm-lens has long startup time #22

jhrcek opened this issue Jan 23, 2018 · 4 comments
Assignees

Comments

@jhrcek
Copy link

jhrcek commented Jan 23, 2018

There's a noticeable lag when I start up atom. Atom's timecop package shows this

screenshot from 2018-01-23 03-54-29

Here the plugin took over 40s to startup. It seems the startup time depends on which directory I start atom in.

When I run it inside small project (atom ~/path/to/my/project), it takes 0.5s to start
When I run it inside my home directory (atom .) it takes 40s to start

@mbuscemi mbuscemi self-assigned this Jan 23, 2018
@mbuscemi
Copy link
Owner

Probably has to do with the fact that I'm searching for Elm files using synchronous file system commands. I'll have to explore the implications of doing that asynchronously.

Also, I'm filtering out "node_modules", "elm-stuff", and directories that begin with ".". Are there other structures in your file system that can be safely passed over, or do you simply have a super-complex folder hierarchy of your own making?

@jhrcek
Copy link
Author

jhrcek commented Jan 23, 2018

No complex structures, just a lot of files :) It's just that I don't use atom for elm programming, but sometimes I need to open complex java project (with thousands of files), in which case waiting for editor startup for 20 seconds is annoying. I can disable elm-lens in such cases, but I consider it suboptimal. Otherwise I like the plugin very much :)

@halohalospecial
Copy link

Maybe only start processing when the opened file is a .elm file?

@sigod
Copy link

sigod commented Mar 28, 2021

Just stumbled on this issue.

image

Are there other structures in your file system that can be safely passed over, or do you simply have a super-complex folder hierarchy of your own making?

I have a couple of Rust projects open at the same time. Rust's target folder is famous for containing a huge number of files. For example, target of one of the more complicated projects:

Total space occupied:
22,804,577,162 bytes in 41,557 file(s),
in 4,029 directories

(= 22,270,094k, 21,748M, 21G)

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

No branches or pull requests

4 participants