Improve generator performance

[gzzhanghao]

This PR aims to fix the performance issue for babel-generator, see T6884.

Here is the result from the same app in the discussion.

===== Origin =====
babylon 265
babel generator 2238
acorn 107
escodegen 355
esprima 95
escodegen 322
===== Optimized =====
babylon 296
babel generator 662
acorn 113
escodegen 355
esprima 106
escodegen 317

[codecov-io]

Current coverage is 85.12%

Merging #3283 into master will decrease coverage by -0.18% as of e9fae4c

@@            master   #3283   diff @@
======================================
  Files          215     215       
  Stmts        15751   15703    -48
  Branches      3373    3360    -13
  Methods          0       0       
======================================
- Hit          13436   13367    -69
- Partial        679     694    +15
- Missed        1636    1642     +6

Review entire Coverage Diff as of e9fae4c

Powered by Codecov. Updated on successful CI builds.

[amasad]

can you add type annotations?

[amasad]

This is awesome! I'm excited for this. Mostly looks good just a couple of suggestions/questions

[amasad]

ok, will merge tomorrow. Do you have any more ideas for optimizations? (this is awesome)

[gzzhanghao]

@amasad not now, but I'll keep finding performance issues in the code base : )

[hzoo]

Maybe we should add some perf metrics whenever we updated some of the packages like babylon/babel-generator like in https://phabricator.babeljs.io/T6884#70050?

Unless we want to bring in a larger file, the largest built file we have is babel-polyfill/dist/polyfill

[gzzhanghao]

@hzoo agree, we can add some identity test case and measure the running time for each package. like escodegen's identity test

[sebmck]

Thank you @gzzhanghao, you're amazing!

[hzoo]

Would it be possible to run a perf.js test on a PR (would be cool to get a comment on the PR like code coverage)? Or we could do it in between releases too.

We can test the parser on different files/libraries, and then the generation?

[robcolburn]

Since we are using array-style access on a string, do we need worry about multi-byte characters, ex: Chinese, Emoji.

I'm not super familiar with Babel's code-base, so that may already be broken, or not something we need to concern ourselves with. A test would be great, if we don't have one yet.

[amasad]

Rob: good point, can you please follow up with a task?
@hzoo: great idea! Build it :)

[robcolburn]

@amasad @gzzhanghao,

I think this would be a descent test
https://github.com/gzzhanghao/babel/pull/1

Existing working multi-byte:
http://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=var%20x%20%3D%20%22%F0%9F%98%82%22%3B%0A%0Athrow%20new%20Error(%22%F0%9F%92%A9%22)%3B%0A

[hzoo]

@robcolburn if we don't have a test for it already we'd appreciate a PR for some!

[robcolburn]

@hzoo I didn't see a test for it, so I PR'd a few to @gzzhanghao branch - https://github.com/gzzhanghao/babel/pull/1

[amasad]

@robcolburn Thanks, going to merge this, so can you PR to master instead?

[robcolburn]

@amasad done #3299