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

Possible performance regression #665

Closed
ghost opened this issue Feb 1, 2018 · 5 comments
Closed

Possible performance regression #665

ghost opened this issue Feb 1, 2018 · 5 comments

Comments

@ghost
Copy link

ghost commented Feb 1, 2018

I ran several benchmarks - including Acorn's own "primitive" benchmark, and it turns out that Acorn is slow on handheld devices, and consumes a lot of memory when it comes to parsing larger libraries - more than 500 lines of code.

Acorn's own benchmark seems to run each test in a separate thread (via Web Workers) and gives a more accurate result than some of the other benchmarks I ran. This prove to me that
Esprima is a horse head ahead when it comes to performance on hanheld devices.

The interesting part here is that older versions of Acorn 5.2x and older are actually around 10% faster than current Acorn version. In my benchmarks tests run on an Intel i5 7th gen with 8 GB RAM.
So my gut feeling telling me that there are some kind of performance regression here.

I also run tests against the Cherow parser, and that parser is twice as fast as Acorn, and performs relative good on handheld devices too. On larger libraries Cherow is actually up to 60% faster than Acorn when I parsed TypeScript (30k lines of code).

I'm aware that a single-threaded JIT compiler can get warm/hot enough after doing a particular processing over and over again before the compiler start switching to a different optimization mode., and that may be the case with Cherow, but still in a "cold JIT" mode that parser is more than a horse head ahead of Acorn.

Babylon (Acorn clone) is relative slow, but if you isolate some part of the Babylon code and do a benchmark comparison with Acorn - Babylon is faster. I noticed this is the case when it comes to regular expression parsing, and classes.

I also did a lot of comparison against all parsers I could find on GH, and it proved to me that even the Acorn and Esprima is almost equal in performance there are room for performance improvements as I see it.

To backup my claim. Run the benchmarks for yourself and you will notice it.

@ghost
Copy link
Author

ghost commented Feb 3, 2018

Ran the benchmarks test again now with the "new Firefox" browser. Latest version of Acorn is now marginally faster than Esprima, but still it perform worse than Acorn 5.2.x.

And magically enough, latest Acorn is faster than Acorn 5.4.0.

The difference in performance I mentioned earlier between Babylon and Acorn is non-existing in Firefox.

When the comes to Acorn and the Cherow, the performance differences are even worse in Firefox except for the ember library - almost equal. For other libraries Cherow is more than 10 horse heads ahead.

@ghost
Copy link
Author

ghost commented Feb 4, 2018

bench

@ghost
Copy link
Author

ghost commented Feb 26, 2018

Just to inform that after implementing regular expression parsing Acorn lost 10 - 15% performance in a lot of libraries such as Jquery, Jquery Mobile and Angular v. 1.6. This is an Acorn vs Esprima comparison. Acorn is still faster than most of the other parsers except this Cherow parser.

@marijnh marijnh mentioned this issue Feb 26, 2018
4 tasks
@KFlash
Copy link

KFlash commented Feb 27, 2018

@marijnh j There are almost zero perf difference between Acorn and Esprima with latest version. If you try my online speed comparison you can test it yourself. Esprima is only around 100 ms faster than current Acorn version.

On a mobile phone the difference between acorn and esprima is around 800 ms. And 2700 ms between acorn and cherow

@marijnh
Copy link
Member

marijnh commented Sep 10, 2018

I'll merge #655 soon, which should help there, and I welcome further performance work, but I'm going to close this as not being terribly actionable.

@marijnh marijnh closed this as completed Sep 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants