LESS file compiling 3x (or more) slower in Firefox

[levi]

I have been using Chrome with less.js. The compile time is around 500ms for a 9000 line less file with about 11 different imports being prefetched with XHR. However, when I run the same project in Firefox, the fastest compile time I encounter is about 1600ms. Sometimes it increases up to 4500ms.

Is there a reason for this slow down in performance on Firefox and are there any way to improve the speed beyond restructuring my LESS document?

[Soviut]

9000 lines seems really long. Are you taking advantage of the ability to nest rules? Are your rules cascading as simply as possible, or are you targeting lots of individual elements?

Regardless, when you go to production, you should compile the LESS file to CSS and reference the CSS file. I recommend a tool like SimpLESS:

http://wearekiss.com/simpless

[levi]

@Soviut Thanks for the tip. Majority of the file is using standard CSS with some nested content inline. I would assume this would parse faster through the compiler on account that it doesn't require preprocessing. I am using compiled CSS in production, but this is off topic from my original question.

I am more curious as to why the processing of the LESS is slower on Firefox over Chrome, when it is the exact same file being processed. My understanding of SpiderMonkey is that it performs equivalently, if not faster than Chrome's V8. I have tested the rendering with and without Firebug running, and I have received the same results. There must be a known reason why Firefox is less performant, and I find it interesting that I have not found anyone encounter similar issues.

@riebel seemingly encountered a similar issue about a year ago and filed an issue (#437). However, he seemed to have fixed the issue by changing an about:config boolean that is false by default in Firefox 15.0.1.

[Soviut]

I don't think it would parse faster because there's more of it. Even if it's standard CSS it doesn't mean it doesn't have to be tokenized and processed just like any of the LESS-specific rules.

Chrome's javascript engine is significantly faster than Firefox's. The amount of time it's taking your script to parse even in Chrome is rather high.

Regardless, I strongly recommend restructing your LESS file to take advantage of nesting, mixins and other features to make your stylesheet as DRY (http://en.wikipedia.org/wiki/Don't_repeat_yourself) as possible. Not only should you be able to significantly reduce the number of lines and speed up the parsing, but you'll also have a much easier to maintain stylesheet.

[Soviut]

Also, keep in mind that any browsers with local storage support will cache the compiled LESS styles so if nothing changes, it will only take a long time to load once.

[Umap]

I am facing the same issue in live. Can anyone help in this?

[lukeapage]

If you care about performance at all then stop using less.js in the browser in live.

The intention is that less.js is used in the browser a) for development b) in some cases where you are editing a theme and want to see the result etc.

In both of these cases speed is not important. Browser issues at very low priority and browser speed issues not important at all.

Having said that if you track down a flaw and can make less.js faster in the browser and not make the code more complicated then I think we would be happy to accept a pull request.

[cloudhead]

V8 is much faster for the kinds of things Less does.. Since very early on, I've measured a ~2x difference.

[levi]

@cloudhead Thanks for your input into this discussion. I've ended up using an Apache module to compile LESS in development, thus the performance of less.js is no longer an issue for me. However, this performance issue does interest me. Have you researched further into which areas are less performant?

[Soviut]

Large files are always going to perform poorer than smaller ones. This is because of the number of lines and tokens that need to be analyzed. So a properly nested LESS file is generally going to compile faster than a flat CSS file. Even the CSS file that LESS outputs would typically take more time to compile back through LESS.

[cloudhead]

@stillmotion not really, but in general, the two VMs are very different - V8 doesn't use bytecode at all, it compiles everything to machine code, while tracemonkey does that on the fly, on hot code-paths. For LESS, there might not be that much of a hot code path, as there are different functions for each type of token and expression, and they are all in use equally, so the batch-compile approach of V8 might be better suited.

[lukeapage]

@cloudhead not sure thats the right way round. V8 compiles quick and dirty, then on hot code paths uses type information built up to create optimised machine code which then is reverted back to the quick and dirty if it gets an argument that is not a type it has optmised for... firefox used to compile one-time straight to machine code but with firefox 18 and the release of ionmonkey they will be going via byte code in order to do the same kind of optimisations that V8 does.

from the two blogs I follow:

https://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-firefox-18/

http://wingolog.org/archives/2011/08/02/a-closer-look-at-crankshaft-v8s-optimizing-compiler

[lukeapage]

things are getting slower with more features and we continue to stress people should only use the browser version when a) debugging b) they really need to and I'm not sure things are going to get quicker or we will have time to spend on optimisation.

[Soviut]

While I agree about not relying on speed in the browser, it wouldn't hurt to eventually have some way of properly profiling the code to see where the hotspots are.

[lukeapage]

@Soviut I would just need to run less in the chrome profiler. Its a
complicated beast and there are optimisations there.. but also the later
changes have favoured more understandable code over speed. Things like
extends and sourcemaps even if not used have just made things a lot slower.
Anyone is free to send a pull request, but this issue is so far down the
priorities I closed it.

[Soviut]

I agree again, I'm thinking more in terms of less compilation through node getting too slow since it has a major advantage over SASS in that area. Having a profiling/optimization strategy in place is possible without putting any real effort into optimization itself.

[chhantyal]

I wish someone could look into this or keep the issue open.

I recently switched to Firefox as my default browser, and this issue is really annoying that first broken page appears and after sometime LESS does it's thing and final page is displayed properly.

Obviously, I use LESS for developing and compile to CSS in production.

[lukeapage]

We know its one or more regular expressions. I keep meaning to work on this but get distracted. I will try tonight.

[lukeapage]

My current guess based on reports we've had is that it effects long less files only and is caused by one or more of the regular expressions, probably because I removed chunking of the input (it was causing a bug). If its 1 regexp causing the issue we can fix - if its all then we are stuck.

Can someone post or send me their large css file showing worse performance in firefox? I cannot reproduce a browser difference with bootstrap.

You can try setting chunkInput to true (its an option) and let me know if it improves things too. The solution may be to split up your less files so you do not have 1 massive one.

[chhantyal]

@lukeapage The usual convention with LESS files is to split into multiple files and import in single file. It's not different from having one big file, right?

I will try to reproduce the it.

[himanshuwt]

I'm also facing performance issue while compiling 17k lined LESS file to CSS on the client side. Can you help me?

[seven-phases-max]

@himanshuwt

I'm afraid the only proper help in this case would be to say: "Do not compile at the client-side".
There's no secret option or a hack to make it faster.

Except a few specific edge-cases ("online Less-to-CSS compile tool", "Theme/framework show-case demos" and similar stuff) there's no fair reasons to go with the browser-side script.
And if you do choose a browser script way you are automatically agreed with a poor performance
(While certain improvements are possible, there simply no volunteers to contribute to this area. Though the PRs are always welcome).

[himanshuwt]

@seven-phases-max
Thank you for information.
I agree with you but I need to increase performance anyhow, we're working to create a theme editor in which user can create their own theme.

[seven-phases-max]

I need to increase performance anyhow

Like at any cost and in infinite time? (OK, just jocking).
So I guess this can be split into three or so steps:

1. Find what can be optimized at the project side. Like "Do all subparts of this 17k-lines thing actually depend on the theme values?" (Usually not, so do not pass the constant parts through the Less compiler).
2. Check if some (relatively light-weight) tricks may help (e.g. Imports referenced more than once seem to be parsed multiple times #2640, Cache parsed imports for faster and incremental build #2746 - sometimes they do, sometimes they don't).
3. Finally optimize the compiler itself (start with considerations made in use global regexes (cached) for small speed improvement #2501 and caching parse results for rebuilds #3145 and be prepared for weeks wasted of your karma impovement for 5% speed boost, months for 20%, etc.).

[matthew-dean]

Finally optimize the compiler itself (start with considerations made in #2501 and #3145 and be prepared for weeks wasted for 5% speed improvements, months for 20%, etc.).

I wouldn't call it "wasted" 😉 If someone wants to help a bunch of people out, that work is always welcome. There are probably lots of potential places to optimize. I think one unknown with that is how you concretely verify the difference in code A vs code B in terms of performance. I don't know of any easy way to do that. I've said it before, but that's probably some low-hanging fruit to figure out before trying optimization work.

[seven-phases-max]

_{Indeed. I should minimize my use of demotivating generalizations.}

[matthew-dean]

Indeed. I should minimize my use of demotivating generalizations.

Haha it’s all good.

[himanshuwt]

Thanks @seven-phases-max
I will try to optimize my code.