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

Large library continues to slow down compile time, even though there are no changes. #74

Open
Bertie2011 opened this issue Jul 28, 2023 · 4 comments

Comments

@Bertie2011
Copy link

Bertie2011 commented Jul 28, 2023

Hello, I'm back 😅

The library we have been using (which was already pretty big) decided to include their font icon library as dependency. Running a full compile takes like 5-10 minutes. This would be okay if it was the first time only, but every time any of our project files changes it seems to hang for that same amount of time. Only when not a single file is changed, it finishes within 5 seconds.

Is this a bug? Can we change our configuration to compile different scss files into separated .css files (even though they @import each other)? How can we get back to blazingly fast compile times?

Also, how can we get more insights into what the tool is doing? It might be nice to include some kind of verbose flag somewhere.

Reproduction case is attached.

  1. After downloading, go to .config/dotnet-tools.json and in Properties check the box to unblock.
  2. Run the script (if Smart Screen pops up, select More Info, Run Anyways), not sure if it will take a long time or will be fast.
  3. Run again, should be fast.
  4. Change my-styles.scss and try again, now it should take like 10 minutes.
    slow-scss-compilation.zip
@stefanloerwald
Copy link
Member

Hi @Bertie2011,

The library not only looks large, but also involves a lot of files. To determine what needs to be compiled, a lot of files need to be read / checked for changes, so it seems expected to me that this would be very slow. To find out whether there's room for improvement, I recommend executing the compilation step by cloning this repo and running the compilation command from Visual Studio and look at the profile of the second run.

Hope that helps,
Stefan

@Bertie2011
Copy link
Author

Bertie2011 commented Aug 16, 2023

Hi Stefan,

I don't think I have enough time and understanding to really figure out what's going on here. Perhaps we can do some rubber ducking... The strange thing is that if files haven't changed it's very fast (leading me to the conclusion that change checking is performant enough), it only bogs down if any other file has changed. This behaviour makes me think that (perhaps in configuration) it's missing some ability to use partial files to quickly collect unchanged chunks.

Would it be possible to define such a "chunk" for the library that this tool could use once it figured out that no files changed in the library folders?

Thank you for your time!

-Bertie2011

@stefanloerwald
Copy link
Member

I suspect that some files are not cached? I imagine it goes something like this:

  • your_main_file.scss
    • first_dependency_still_your_code.scss
      • /third_party/megalib.scss
        • /third_party/dependency_hell.scss
          and so on

If in compilation it goes

  • your_main_file.scss cache as your_main_file.css
  • first_dependency_still_your_code.scss cache as first_dependency_still_your_code.css
    • /third_party/megalib.scss included but not cached
      • /third_party/dependency_hell.scss included but not cached

then the cached state would save you from long compilation times if both your_main_file.scss and first_dependency_still_your_code.scss remain unchanged. But as soon as either of those files gets changed, the entire dependency tree would need to be searched again, I suppose.

If you see all those css files next to the scss files, then this hypothesis is false. Otherwise it might be the culprit.

@Bertie2011
Copy link
Author

Bertie2011 commented Aug 18, 2023

Ah... "Caching" is the word I was looking for I guess. Yeah it's most certainly that this is where it's going wrong. The SCSS transitions at an arbitrary folder depth / name from internal files to dependency files so I don't think the compiler would be able to figure out how to build this cache tree. (I verified that this is what's happening)

I had a look at the configuration parameters of the DartSassHost library, but couldn't find a clear answer on how to define cache rules. Do you know of any ways on how to do this?

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

No branches or pull requests

2 participants