Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework vs Postcss speed bench #64

Closed
MoOx opened this issue Jul 29, 2014 · 34 comments
Closed

Rework vs Postcss speed bench #64

MoOx opened this issue Jul 29, 2014 · 34 comments

Comments

@MoOx
Copy link
Contributor

@MoOx MoOx commented Jul 29, 2014

I'm curious to know if speed diff with rework is it's just because of keeping use whitespace & coding style.
https://gist.github.com/MoOx/1b0d7d2bd987e0735e0e
Any comment ?

@ai
Copy link
Member

@ai ai commented Jul 29, 2014

Yeap, now PostCSS made few RegExp match on every node parsing to split spaces correctly. I think with tokenaize step before I can reduce RegExp and allow to autodetect at-rule content #41

@ai ai added the enhancement label Aug 5, 2014
@ai ai added the v3.0 label Sep 21, 2014
@ai
Copy link
Member

@ai ai commented Sep 21, 2014

PostCSS will not be faster that Rework, but tokenizer get some speed boost.

Current:

PostCSS:     775 ms
CSSOM:       163 ms (4.8 times faster)
Rework:      314 ms (2.5 times faster)
Gonzales:    776 ms (1.0 times slower)
Gonzales PE: 761 ms (1.0 times faster)

My private tokenizer branch:

PostCSS:     480 ms
CSSOM:       224 ms (2.1 times faster)
Rework:      379 ms (1.3 times faster)
Gonzales:    735 ms (1.5 times slower)
Gonzales PE: 698 ms (1.5 times slower)
@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Sep 21, 2014

Awesome news !
Great work :)

@yisibl
Copy link
Member

@yisibl yisibl commented Sep 25, 2014

💯

@ai
Copy link
Member

@ai ai commented Oct 4, 2014

Good news, everyone!

@Termina1 made really amazing work and speed up new tokenizer branch. PostCSS 3.0 will be fatser, that Rework.

Current PostCSS 2.x:

PostCSS:     426 ms
CSSOM:       107 ms (4.0 times faster)
Rework:      194 ms (2.2 times faster)
Gonzales:    468 ms (1.1 times slower)
Gonzales PE: 470 ms (1.1 times slower)

New tokenizer branch with @Termina1 fixes:

PostCSS:     139 ms
CSSOM:       99 ms  (1.4 times faster)
Rework:      181 ms (1.3 times slower)
Gonzales:    416 ms (3.0 times slower)
Gonzales PE: 406 ms (2.9 times slower)
@ai ai mentioned this issue Oct 4, 2014
@ai ai closed this Oct 4, 2014
@kizu
Copy link

@kizu kizu commented Oct 4, 2014

That's some really awesome news!

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Oct 5, 2014

👍 👍 👍

@magsout
Copy link
Member

@magsout magsout commented Oct 5, 2014

Very good job

@andreypopp
Copy link
Contributor

@andreypopp andreypopp commented Oct 6, 2014

🚀 🚀 🚀

@ai
Copy link
Member

@ai ai commented Oct 24, 2014

Unfortunately, es6-transpiler has side effects and as I found out it slow down some JS code (mostly CSSOM and Rework). Currect tokenizer branch uses 6to5 and has more honest benchmark:

CSSOM:       27 ms  (2.3 times faster)
PostCSS:     62 ms  
Rework:      63 ms  (1.0 times slower)
Gonzales PE: 163 ms (2.6 times slower)
Gonzales:    170 ms (2.7 times slower)
Stylecow:    219 ms (3.5 times slower)

Also I start to use Bootstrap CSS, because it has whitespaces and comments indead of GitHub CSS. And now benchmark contains Stylecow.

@ai
Copy link
Member

@ai ai commented Oct 26, 2014

BTW, I suggested to @brainopia and @Termina1 2 boutles of Ruby porto award if they will increase PostCSS perfomance for 2 times (to 30-40 ms for parsing Bootstrap). Maybe somebody want to join this competition? ;)

@ai
Copy link
Member

@ai ai commented Nov 1, 2014

I disable node.source generation if user doesn’t want to add source maps and it increase perfomance up to 30%:

CSSOM:       27 ms  (1.8 times faster)
Mensch:      47 ms  (1.1 times faster)
PostCSS:     49 ms  
Rework:      64 ms  (1.3 times slower)
Gonzales PE: 171 ms (3.5 times slower)
Gonzales:    179 ms (3.6 times slower)
Stylecow:    206 ms (4.2 times slower)
@ai
Copy link
Member

@ai ai commented Nov 10, 2014

You will not belive, but @brainopia won perfomance contest! The new tokenizer is incredibly fast!

PostCSS 3 become the fastest CSS parser, written on JS! We are about 20 % faster, that even CSSOM and about 3 times faster, that Rework (don’t forget, that we still parse and store whitespaces).

PostCSS 3:   23 ms
CSSOM:       28 ms  (1.2 times slower)
Mensch:      47 ms  (2.0 times slower)
Rework:      62 ms  (2.7 times slower)
Stylecow:    122 ms (5.3 times slower)
PostCSS 2:   141 ms (6.1 times slower)
Gonzales PE: 162 ms (7.0 times slower)
Gonzales:    175 ms (7.5 times slower)
@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 10, 2014

This is so fucking cool. Thank you guys !!

@lionelB
Copy link

@lionelB lionelB commented Nov 10, 2014

you guys rocks ! congrats @brainopia

@kizu
Copy link

@kizu kizu commented Nov 10, 2014

Awesome! 🚢

Although, I guess PostCSS is still partial parser (got this definition from the Stoyan's talk here), as it won't parse all the stuff (all the simpleselectors, contents of :not, attr selectors, values like gradients, transforms etc, etc.), while parsers like Gonzales are trying to parse just everything.

But whatever. Impressive work is going on there!

@ai
Copy link
Member

@ai ai commented Nov 10, 2014

@kizu yeap, Gonzales parses more :).

@ai
Copy link
Member

@ai ai commented Nov 11, 2014

PostCSS 3.0 with new parser was released today. Please, test :).

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

I add benchmark with preprocessors parsers: dce2f3e

PostCSS is few times faster even that libsass:

PostCSS:   19 ms
libsass:   106 ms  (5.5 times slower)
Less:      150 ms  (7.7 times slower)
Stylus:    278 ms  (14.3 times slower)
Ruby Sass: 1078 ms (55.5 times slower)
@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

This kind of bench should be done with some plugins added. For example you should consider use cssnext to compare sass & friends ;)

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

@MoOx there is no cssnext features in Sass ;). Maybe when I add Sass style variables and @mixin we can compare with some logic inside.

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

I mean that making bench with a parser (postss) & parser + features (sass, less etc) doesn't really make sense. cssnext that use postcss add some features like vars, math, custom media etc. so it's a bit more logic to compare old preproc to cssnext, more that comparing them to postcss only.

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

@MoOx I agree, but cssnext vs Sass doesn’t make sense too ;). Correct benchmark should use same features.

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

@MoOx hm. But maybe you are right. Even if test CSS will not contains cssnext features, cssnext AST lookups will make benchmark little better.

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

Even if cssnext doesn't have mixins/if/loops, you have similar features like vars, math, color manipulations. It's better than nothing ^^

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

This kind of bench are just sort of "just to let you know" :D

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

Yeap, I updated benchmark: 7b0e467

PostCSS:   36 ms
libsass:   110 ms  (3.0 times slower)
Less:      157 ms  (4.3 times slower)
Stylus:    286 ms  (7.9 times slower)
Ruby Sass: 1092 ms (30.1 times slower)
@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

You should add the output to a file like BENCHMARKS.md or something like that & update it on each release to make this even more cool :)

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

@MoOx maybe yu know some service, that can run benchmarks on every commit and output graph of perfomance?

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

we can probably update your task to save the output + run the task on the prepublish npm script ?

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

and where we will store results and print graph?

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

I think the evolution is not the most interesting thing.
The current state on a release is the interesting thing.
The result (output) should be easily retrieved from a child process.

@ai
Copy link
Member

@ai ai commented Nov 24, 2014

@MoOx I want this graph for PostCSS developers to prevent perfomance regression :)

@MoOx
Copy link
Contributor Author

@MoOx MoOx commented Nov 24, 2014

Oh yeah. But that would be another problem. Can be drawn from collecting git history values on the versionned bench output ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.