Open STRML opened 4 years ago
FWIW, I can get the average time down to 9 sec real
just by replacing:
with:
this.__keys = visitor.keys || VisitorKeys;
with no loss of functionality.
@STRML Thank you for your suggestion!
This is the first babel plugin I've seen that simply uses a Program entrypoint
Because babel-plugin-espower requires massive AST rewrite on leaving nodes (not entering nodes) so cannot coexist with other plugins rewriting nodes on enter. Some babel plugin that also require massive rewrite, such as babel-plugin-istanbul uses Program
node as entrypoint and traverses by itself.
then uses estraverse all over rather than use the visitors provided by Babel itself.
Nice point, as the time I wrote babel-plugin-espower babel traverser is feature rich and slower than estraverse so I chose estraverse. But now you found estraverse's functions the heaviest, It's time to reconsider implementation details (maybe babel gets much faster than ever). Thanks a lot.
One more nice suggestion you gave me is the initialization cost of estraverse. There's much room for improvement to make estraverse to not to initialize it on every traverse call.
I'll work on them. Thank you!
This is the first babel plugin I've seen that simply uses a
Program
entrypoint then usesestraverse
all over (https://github.com/power-assert-js/babel-plugin-espower/blob/4932320d9eecffca0dc38dc7fc2684ffffca1c6c/lib/babel-assertion-visitor.js) rather than use the visitors provided by Babel itself.This additional/redundant parsing makes
estraverse
's functions the heaviest in a profile run of one test file, screenshotted below:This leads to us finding
estraverse
code at the bottom of a significant proportion of the flame graph:How necessary is this module? Can the plugin be modified to follow babel conventions more closely?
Time with babel-plugin-espower enabled:
With it disabled: