Open jhrcek opened 6 years ago
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?
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 :)
Maybe only start processing when the opened file is a .elm
file?
Just stumbled on this issue.
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)
There's a noticeable lag when I start up atom. Atom's timecop package shows this
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