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

Performance of js2-parse #524

Closed
wol81 opened this issue Apr 13, 2019 · 6 comments
Closed

Performance of js2-parse #524

wol81 opened this issue Apr 13, 2019 · 6 comments

Comments

@wol81
Copy link

wol81 commented Apr 13, 2019

My question is: What is your impression about the performance of (js2-parse)?

I implemented code analysis on top of js2-mode, in order to achieve better support for completion, navigation, and such in the context of our projects (quite a bit specialized, based on our way to use Dojo in our projects).

For some js file with about 2000 lines of code (I can't simply publish it as it's proprietary code), I experienced bad performance of js2-parse. I then compared:

  • running time around 0.4s with the js2-mode version of 16th January 2017
  • running time around 1s with the current js2-mode version

(the js2-mode.el was byte-compiled in both cases, both with the emacs version (24.5.1) I currently use)

So, parsing time for that file increased significantly over the last two years.

As I haven't really time to dive into that parsing code myself, I have the following questions:

  1. Do you have an explanation for that? Are there known changes, that were necessary for the sake of correctness, but caused a known performance penality?
  2. What is your opinion about the overall performance of js2-parse? Could it become faster with some amount of work, or is your impression that it's as fast as it can be based on Lisp?

For me, this means that for now I will stay with the 2017 version, as already 0.4s is quite much in terms of user experience.

@UwUnyaa
Copy link

UwUnyaa commented Apr 13, 2019

What about a newer version of Emacs? There might be some backwards compatibility code that isn't as fast as how it's implemented in newer versions of Emacs, as well as improvements to the byte code compiler.

@dgutov
Copy link
Collaborator

dgutov commented Apr 14, 2019

Have you tried it in Emacs 25? It will require a recompilation to see the speed-up.

Or, in Emacs 24.4 or newer, you can (setq byte-compile--use-old-handlers) in your init script, and then reinstall the package to trigger the recompilation.

Of the recent changes, the one that is likely to have caused such a slowdown is the transition to lexical binding: t. But the new condition-case handling introduced in Emacs 24.4 (and made default in 25.1) should recover most of the difference, if not all.

@wol81
Copy link
Author

wol81 commented Apr 14, 2019

You are right, on emacs 26.2, the current js2-mode version is just slightly slower than the 2017 js2-mode version (something like a 0.4s vs. 0.45s difference).

Thanks for that hint, and the reason why I use that old emacs version is simple: Debian Stable.

@dgutov
Copy link
Collaborator

dgutov commented Apr 14, 2019

🤷‍♂️ You can try the other solution I suggested, then.

@dgutov
Copy link
Collaborator

dgutov commented Apr 14, 2019

BTW, https://repology.org/project/emacs/versions says Debian Stable includes 25.1 already.

@wol81
Copy link
Author

wol81 commented Apr 14, 2019

Ah, thank you again, I didn't notice (or forgot) that the emacs versions are arranged in separate packages, i.e. I had to install the package emacs25 instead of just updating...

@wol81 wol81 closed this as completed Apr 14, 2019
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

3 participants