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

add perf comparison to pretty-format #31

Closed
capaj opened this issue Jun 30, 2017 · 1 comment
Closed

add perf comparison to pretty-format #31

capaj opened this issue Jun 30, 2017 · 1 comment

Comments

@capaj
Copy link

capaj commented Jun 30, 2017

I'd like to see which package does it faster because it seems to me both are doing pretty similar thing.
https://github.com/facebook/jest/tree/master/packages/pretty-format

@capaj capaj changed the title perf comparison to pretty-format add perf comparison to pretty-format Jun 30, 2017
@novemberborn
Copy link
Member

I've actually included the performance test from pretty-format in this repo, though I haven't kept it up to date or run it in a while. Currently soundness is more important than performance.

The tl;dr is that pretty-format is undoubtedly faster, and Concordance won't ever beat it in performance. But, that's not what Concordance was built for!

The first performance hurdle is that Concordance creates descriptor objects for the value being formatted. These objects carry the comparison, formatting, diffing and serialization logic.

The second hurdle specific to formatting is that Concordance creates objects for each formatted line, and creates line buffers as it walks the value being formatted. These objects are needed so diffing can reuse the formatting logic. pretty-format just uses string concatenation. You'd diff those output strings, whereas with Concordance diffing happens on a structural level.

Lastly Concordance formats more aspects of JavaScript values, which may or may not be significant. It can make performance tests misleading though: depending on the value being formatted Concordance inevitably has to do more work, regardless of the aforementioned performance hurdles. Error objects are a good example here.

For AVA the idea is that comparisons should be fast (enough). If all your tests pass there is nothing to format, so formatting performance is less important.

This may not hold true for other use cases. You'll have to decide which formatting output fits your use case and whether the performance differences are important enough.

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