This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have a .less file with close to 1000 lines.. for the last 2-400 lines or so added to the file, the editor has just been unbearably slow. I can literally hit a number of keys and then watch the changes occur step by step, like a slow-motion recording of what I'm doing. At this point I'm using Notepad to paste in bulk changes. It should be noted that I'm on a fairly recent computer with most of the bells and whistles a developer could want to make their daily VS life tolerable. Is this a limitation of WW or could it be a conflict with some other extension? Looking for recommendations or advice to help alleviate the problem. |
|
|
I don't think it's a limitation of Web Workbench. I just created a 3000-line Less file (admittedly with fairly simple rules in it) and entered some stuff at the end, and didn't see any problems. Admittedly this is a pretty fast machine, but I saw no degradation at all in typing speed. (Sometimes highlighting could take half a second or so to catch up, but the display always remained responsive -- just the newly inserted text was uncoloured for a moment.) There are a couple of possibilities:
|
|
|
I'm positively relieved that it shouldn't be a WW limitation :) I just looked at Task Manager, and the VS process was using about 2.1GB, which is pretty much whatever it can allocate. I think the slowdowns occur because of a memory leak somewhere that eventually causes the process to spend all its time disk swapping. It could be a bug in any one of my extensions, but I would say that WW is a likely candidate, as the problem is recent and WW is a relatively new addition to my workflow. That said, if nobody else is seeing this then perhaps the culprit is elsewhere. I've disabled a few extensions and will experiment to see if the problem persists. |
|
|
Do feel free to flick us the problematic file. If nothing else, we can spin it up and just let you know whether we see the same issue or not, which might save you chasing red herrings! |
|
|
Hmm, maybe I was being too fast there. I've restarted VS and its currently using about 800 MB of memory (up from 400 before I loaded the project), but the less editor window is still slow as a bugger. Perhaps a tad faster than when the machine was also disk trashing ;) I've attached the set of less files I'm using, in case you have time to try them locally for comparison. PS: Am using WW 3.0.66.19873. |
|
|
Thanks. I've tried your three files here and am unable to reproduce either a memory leak or a performance problem. I even tried copying and pasting the contents of mf.less a couple of times to make the file even bigger, and I'm still seeing no slowdown. This machine does have a lot of memory and a SSD drive but even so VS is sitting steady around 230MB so I don't think it's down to me having more memory or a faster disk. (The one case where disk speed might be a factor is where we re-load @imported files to provide intellisense on variables and mixins. But unless your disk is really slow I don't see that as likely -- you're only importing two files and they're both very small.) So right now it looks like it must be an interaction with something else. If you can identify any potential culprits then we'll be happy to test with them and if necessary to work with the authors to resolve the issue. |
|
|
My VS eats 380MB just to start and anywhere from 500MB to 700MB when I open a solution. R# is probably to blame for that, but it has not been a problem in the past. Am using a machine with 8GB RAM and SSD, so is more likely a software than a hardware problem. I've disabled a bunch of extensions and will see if I can pinpoint the problem, but it's a bit like sticking your hand in a river and hoping to catch a fish. I could enumerate all of the tool-extensions and addons I've got on the system, but not sure if that would be of any use. |
|
|
I am pretty sure at least one of our Web developers uses Resharper alongside Web Workbench and he hasn't reported this issue (and I know he has been using it with large files). Unfortunately he's on holiday at the moment so I can't double check with him. I wouldn't rule it out, simply because Resharper has a mixed reputation for perf and likes to involve itself in everything Visual Studio does, but it's not an obvious culprit. (From what I've heard Resharper is actually relatively good at staying out of .less files.) The other one you might want to try temporarily removing (and/or updating if you have an old version) is Web Essentials. Again, it's not that we've had any reports of performance issues with Web Essentials: I mention it only because it's one of the few other extensions I know of that takes an interest in .less files. One thing I can think of that would cause Web Workbench to get busy is if it is saving. Is it possible that something could be causing your .less file to get saved while you are still typing away? Compilation does happen in the background, so it shouldn't block the UI thread, but it could cause load. You'll see the throbbing disk icon in the status bar during a background compile. One thing you could try (as a fairly desperate measure) is to run VS2010 under the profiler and see if there are any obvious hotspots (being sure to profile only a span when you are typing and VS is being sluggish). It may not be very informative because you won't have the symbols, but if the hotspot is in managed code then you should be able to get function names. (All of Web Workbench is managed code so if we are the culprit then you should be able to see us!) If there's any more guidance or info we can provide, let me know. We're keen to understand what's happening and to get it fixed for you! |
|
|
Having said that we've not had any reports of performance issues with Web Essentials, a customer just mentioned that they didn't use Web Essentials because it made the Web Workbench syntax highlighting very laggy. He didn't mention anything about typing becoming unresponsive, but I don't know how big his files were. So if you have Web Essentials installed it might be worth seeing if that is where the conflict is happening. (Not trying to point fingers here -- just passing on some info.) |
|
|
I have now managed to pinpoint the problem (also don't have Web Essentials installed, so that's not it). The slowdown is caused by the Productivity Power Tools extension, and more specifically by the Enhanced Scroll Bar feature. As soon as you go to Tools -> Options -> Productivity Power Tools -> All Extensions and turn off this feature, everything reverts back to normal behavior. No word on whether this also fixes the memory leak, but PPT has had several such problems in the past. I also don't think they're written in managed code, so quite likely overall. Thanks for all your help and effort in reproducing the problem :) |
|
|
I was having the same sluggish performance using WebWorkbench and was very pleased that you pinpointed the problem. It is in deed the Power tools scrollbar. I turned it off and barely selecting lines became faster (which was the slowest feat anyway). @ivan: But... This is still related to WebWorkbenchI wouldn't simply dismiss this as being a problem with Power Tools because the same functionality works just fine in other files. And it has to do the highlighting and intellisense in them just as well. So this still is a problem for WW. It just makes it simpler for them to investigate into this. Now they have all the information to start solving this issue. But just to make sure, I was using the simplest scrollbar (called Scroll bar mode) that just highlighted with some coloured dots on it. No mapping that shows extremely zoomed out code. And my SCSS file only has about 300 lines of code anyways. Compiled CSS has about 400 of them when compiled with extended directive. But scrollbar performance is not a problem at all. When I move around the CSS file scrollbar displays those dots, but it's not sluggish. It's seamless... No such luck in SCSS file... |
|
|
Just wanted to offer some insight on this from my experience. I was working to create some traditional CSS to SASS with WebWorkbench. I have a main SCSS file and 12 additional partials that I import into the main. I have PowerTools installed and everything was fine -- until I started using @mixins combined with @imports. With my @imports, adding just one single, simple @mixin causes a noticable slowdown. By the time I had added a few more, VS became completely unresponsive and essentially impossible to use. Turning off WW intellisense didn't seem to do anything for me. However, if I comment out the @mixin definitions OR the @imports, the performance problem goes away. An example of my SASS:
I've never had any performance issues until WebWorkbench was installed, and given that I can reproduce this so easily with the pattern above, I have to agree that there's something fishy about WWB going on here. For now, I guess I'm going to have to do it the old CLI way :) My extensions:
Edit: After searching through the forums I've found some other posts that seem to confirm part of my suspicions: |
|
|
A quick update on this: We have determined that the problem occurs because Enhanced Scroll Bar asks Web Workbench for error info basically every time the selection changes. When selecting rapidly, this results in a lot of queries to Web Workbench -- and when imports are in play this results in loading and parsing imported files far too often. We are still trying to find a way of resolving this properly, but as an interim measure, we have found that turning off the Enhanced Scroll Bar "Show bookmarks and breakpoints in the scroll bar" option eliminates the performance problem. Of course, this is a global setting and if you frequently use ESB to locate bookmarks and breakpoints then this will not be an option for you. However if you use ESB mainly for change tracking or file maps then we hope this will work for you until we can get you a proper fix. |
|
|
...and there will be a candidate fix in the next nightly build, available from about 1200 GMT. (See the FAQ sticky thread for info on obtaining and installing nightly builds.) Please let us know if you still see problems after installing the nightly. For background, the issue was that ESB was polling us to get the error squigglies for the entire Sass file every time the selection changed, rather than listening for the change notification and updating itself only when the squigglies changed. We now cache our squigglies so that we can return them to ESB more rapidly and this appears to be sufficient to solve the performance problem. Thanks to everybody who provided information to help track this down, and our apologies to you that it took this long to fix. |
|
|
Many thanks for the update to this. I can confirm that turning off the "Show bookmarks and breakpoints in the scroll bar" does indeed have a positive effect. However, please note that it doesn't completely eliminate the issue. When making the .SCSS file tab active, there is a few second delay and when I scroll to a point where a @mixin is visible in the window, it becomes unresponsive for a second or two (I suspect both delays are being cause by the mixins). Nevertheless, it's a huge improvement and makes WWB usable, so thanks again! |
|
|
I have the same problem. Mixins + imports causes the editor to be so slow as to be unusable. If I comment out the imports, I can edit the file. But then I have to remember to remove the comments so the imports are available when generating the file. Extensions:
|
|
|
I can confirm this hasn't got anything to do with the scrollbar for me, the imports are causing the problem. My file is completely unusable with the imports, but when I comment them out the speed dramatically increases. I am working on a machine with an i7 and 12GB RAM, so hardware isn't the issue. |
|
|
I should have mentioned that I have the scrollbar settings disabled, and that doesn't help. Also not a hardware issue here. Dual core i3 @ 3.30 GHz with 8 GB RAM. |
|
|
We have made some performance improvements recently which I believe would be applicable to what you are both seeing - if you have a subscription then I would recommend updating to a nightly build to test this out. If you are using the free version these will be included in the next gallery update in the next day or two. If after updating you continue to see a problem can you send through an example project where this is occuring and I can look into what is causing the issue and look into a fix. I would also ask you to check if disabling the other plugin's and extensions you are using have any impact on the performance.
|
|
|
I have just got the update, and first impressions are really good, speed is much improved! Will keep using and make sure it's not placebo, but considering it was nearly unusable before, I would say it has made a big difference. |
|