-
Notifications
You must be signed in to change notification settings - Fork 1.3k
watcher unresponsive or tremendously slow starting with 3.12.0 #1869
Comments
Are you mistakenly watching your |
It's entirely possible there's a leak in the files array. I had suspected there might be at the time but I couldn't see it. |
No, definitely not watching |
I suspect there may be a memory leak in how we're tracking the graph. I suggest doing some debugging around this array and the graph object. Their size should stay stable if you're not adding or removing files. If they're growing as you're saving then there is something wrong. |
I spent some time looking into this and have been unable to find any kind of leak. |
Ok after a lot of experimentation I was able to reproduce the issue. I was looking the watcher getting progressively slower over time which would suggest a memory leak. However the actual issue is that the watcher is slow to trigger changes on a files with lots of |
the watcher for files with lots of imports. The regression was caused by calling the slow `gaze.add` unnecessarily. We only need to call `gaze.add` on files that aren't currently being watched. At the time I confirmed that calling `gaze.add` in files that were being watched wouldn't result in a leak or multiple events being fired. I however assumed calling `gaze.add` for already watched files would be very cheap. Fixes sass#1869
Watching for changes on files with lots of `@import`s had a significant regression in responsiveness in sass#1745. The regression was caused by calling `gaze.add` unnecessarily. We only need to call `gaze.add` on files that aren't currently being watched. At the time I confirmed that calling `gaze.add` in files that were being watched wouldn't result in a leak or multiple events being fired. I however assumed calling `gaze.add` for already watched files would be very cheap. Fixes sass#1869
Watching for changes on files with lots of `@import`s had a significant regression in responsiveness in sass#1745. The regression was caused by calling `gaze.add` unnecessarily. We only need to call `gaze.add` on files that aren't currently being watched. At the time I confirmed that calling `gaze.add` in files that were being watched wouldn't result in a leak or multiple events being fired. I however assumed calling `gaze.add` for already watched files would be very cheap. Fixes sass#1869
Thanks @xzyfer! I've confirmed this fixes things on our end as well. Nice find. |
Thanks for the confirmation, the fix will be in the next release.
…On 30 Jan. 2017 7:15 am, "Michael Mase" ***@***.***> wrote:
Thanks @xzyfer <https://github.com/xzyfer>! I've confirmed this fixes
things on our end as well. Nice find.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1869 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWMkRPHJJhGs-ZAWj1nWs0N4ZKwRxks5rXPNLgaJpZM4LuVJd>
.
|
Issue:
After 3.9.3, watcher is virtually unresponsive or extremely slow/delayed.Edit: I have narrowed it to https://github.com/sass/node-sass/releases/tag/v3.12.0
npm -v
): 3.10.8node -v
): 6.9.0node -p process.versions
):node -p process.platform
): darwinnode -p process.arch
): x64node -p "require('node-sass').info"
):The text was updated successfully, but these errors were encountered: