Less Compiling Perf

[ctolkien]

VS2013.2, Web Essentials 2.0.11 (nabbed from the nightlies, as RC would not work).

When saving a less file, performance to compile is now pretty terrible, it's at 5 seconds to compile our less file, and then a further 6 seconds to compile dependent less files. Total turn around time ~11 seconds.

13/05/2014 12:50:13 PM: LESS: Compiling Main.less
13/05/2014 12:50:17 PM: LESS: Main.less compiled.
13/05/2014 12:50:23 PM: LESS: dep1.less compiled.
13/05/2014 12:50:23 PM: LESS: dep2.less compiled.
13/05/2014 12:50:23 PM: LESS: dep3.less compiled.
13/05/2014 12:50:24 PM: LESS: bootstrap.less compiled.

Machine is an I7-3770K, 32GB, SSD.

CPU and memory usage are both going haywire.

[ctolkien]

Digging further, can see 4 node processes fire up, after they are done, memory usage remains elevated (2gb+, compared to ~800mb), and CPU remains high (40%+) for another 30 seconds or so.

[SLaks]

This is caused by the source map parser.

[ctolkien]

Thanks @SLaks - Is there some way to disable source maps? I've trawled through the options and under LESS, 'Create source map files' is already disabled.

[ctolkien]

FWIW, nabbed and built from source - issue still persists. Has ground our shop to a halt so if anyone has any ideas, I'm all ears!

[am11]

Lets follow this issue at one place, i.e.; #1040.

[ctolkien]

@am11 back over on this thread (if it's not related to) #1040 - this does improve the performance of VS after compilation_, it does return back to typical usage perf after about 5 seconds after the less compilation is complete, but the actual less compilation is still taking about 9 seconds to complete (and my front end guys are yelling at me :))

For comparison, running gulp-less takes ~500ms for these files..

[am11]

Yes for that matter, we have another issue: #381. As you can see, we are brainstorming for quite a while but haven't devised a tangible solution yet. Plus WebDev team at Microsoft is internally prototyping for built-in grunt/gulp tasks support OOTB, so we might be able to leverage that. Nonetheless, please feel free to chip in there. :)

Incidentally, should we consider this issue fixed? I will send a PR..

[ctolkien]

Hrm, well I can't be sure if this is entirely down to spawning new node processes. I can say that this wasn't a problem in the previous version we were using (1.9 - I think using node is new in 2.0 however?).

~10 seconds to compile less is unusable for us at the moment. Note, that even with compilation disabled (and all the less options disabled), CPU/memory still spikes heavily, and it still spawns a bunch of Node processes on saving. It also still mentions that it's compiling in the output window..

We've had to disable WE from our front end devs machines for the time being (which is a bummer, as obviously it comes with a lot of other benefits).

I've had a look at the source, but it would take me some time to get up to speed - if there is any way I can assist please let me know!

[SLaks]

The problem here is definitely caused by the source maps.
I'll take a look at the code soon.

[am11]

@SLaks, no; I have made it disableable, and with sourcemaps processing disabled (http://1drv.ms/1gyDhBb) they are still facing slow performance on compiling (see e65f289).

Note, that even with compilation disabled (and all the less options disabled), CPU/memory still spikes heavily, and it still spawns a bunch of Node processes on saving. It also still mentions that it's compiling in the output window..

This is definitely compiler and margin. It runs the compiler even when saveOnBuild is disabled and run in-memory compilation for updating preview window. See CompilerRunner Line 52.

However, it doesn't make sense if both preview window and build options are disabled. So I am working on its fixed.

[am11]

Ok now with 8f9d873, it will not compile when compile on save and show preview settings are disabled. Here is the build: http://1drv.ms/1qyfriI.

[am11]

@ctolkien can you please try with http://1drv.ms/1qyfriI?

Disable Process source maps, Compile files on save and Show preview pane and it won't be requiring compilation for anything. The performance improvement is expected to be significant.

[ctolkien]

@am11 appreciate your efforts here! Unfortunately, no change (node is still spawning up and am still getting the 'Compiling' notification in the output window. I have every option for LESS disabled.

[am11]

@ctolkien, some more commits have been made since then. You can test with http://1drv.ms/1gBwpmx.

[ctolkien]

@am11 Can confirm, now with all less options disabled - no longer going haywire!

[SLaks]

Try it with the options enabled too; the parsing should now be orders of magnitude faster.

[am11]

Yes please give it a try with options enabled! :)

[ctolkien]

OK, options on to Save less file on build and save dependent less files.

Compilation time: ~9 seconds.

Post compilation however, VS quickly returns to normal. Memory usage remains ~500mb throughout (rather than spiking to 2gb+)

[ctolkien]

Hi guys, I'd like to reopen this issue as there is currently nothing open (that I can see) tracking the LESS Perf issues. Compilation is still ~10 seconds (using 2.1.3 nightly), compared to straight Node based version which takes <500ms (although Node is already running, so not paying for the process start - there is only one Node process though).

[am11]

#1094 is the similar issue. JsHint uses the same NodeExecutorBase as LESS/SCSS.

For every call to NodeExecutorBase.CompileAsync(_, __), the new node process is spawned from scratch.

As mentioned earlier, all these issues are ultimately related to #381; we need a new architecture for node based compilation/linting, which would make it significantly faster. If you have suggestions about it, please chip-in.