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've just installed latest verision in my VS2010SP1 system. When I go to edit my less file, it takes approximately 3 seconds to process each keystoke. Is there a way to improve this time? It seems to be caused by importing of two other less files. One of which is a renamed jqueryUi themeroller to make mixin's easy. |
|
|
Thanks for reporting this. Unfortunately this isn't something we currently let you control but I will take a look at whether we can avoid re-processing unnecessary import files which should address the problem. Is the themeroller file quite big? By the way, did you have this problem before the upgrade? I don't think we've changed anything in Less highlighting/intellisense, so would be very interested to know if the slowdown is specific to the new version. |
|
|
This is standard Jqueryui theme roller file - 568 lines This is standard 960Grid.css file 388 lines I was importing them as a simple way to generate a single composite, minified css file plus I could do mix-ins. Cool product. One feature that would be nice would be ability to pretty-print / reformat source code
|
|
|
We face the same issue from time to time. Either Visual Studio reports that it has caught an unexpected exception, while editing a .less file, or it becomes inexplicably slow, as if some sort of background process was going rogue. Exiting VS and restarting fixes the situation for some time, so we assume that the .less engine is fine until it reaches some condition, which drives it into hyperactive mode... |
|
|
This seems to be a problem across the board as the source files get longer. I wonder if wrapping some of the more expensive parsing into a different thread would help (ie. Task.Factory.StartNew(() => {})) |
|
|
Cannot answer that question. But I've notice mine situaiton getting progressively slower.
I've reciently completely rebuilt my less file and as the file has gotten longer and more "nested" & mixins, it is getting extremely slow. It is almost like it has reached a tipping point and then when from okay to very slow in a short amount of time. Also, this slowness has made intellisense worse than useless. |
|
|
Thanks for reporting this -- we are trying to prioritise Web Workbench work so it's really useful to know how many people are encountering performance issues. photo_tom, you said that you'd seen something of a tipping point as your file got longer and had more nesting and mixins. Would you be willing to share 'okay' and 'very slow' versions? You can attach a zip file via the Options tab, or email to support (at) mindscape.co.nz if you don't want the files to be public. GeorgeR, we're already doing some work to process the highlighting asynchronously. We will take a look at whether we can offload more work onto background threads, but I think we will probably also have to see if we can improve the parser efficiency. |
|
|
Attached is file that is behaving slowly. I don't have a non-trival "fast" file. Also, something in last upgrade or two, intellisense has become extremely slow. |
|
|
Just to update you on this, we've implemented some optimisations and we're now seeing much zippier speeds in our internal builds. We want to do a bit more testing but we're hoping to have an update out in the next 24 hours or so -- keep your eyes on the Extension Manager! |
|
|
Brilliant - thanks for the update. |
|