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

Mutate the doc.parts array when printing fill #3273

Merged
merged 2 commits into from Nov 16, 2017

Conversation

duailibe
Copy link
Member

Context: #3263 (comment)

Slicing the array means copying the array's content for every pair, which makes the algorithm quadratic. This PR changes the copying to mutating the array directly to prevent that. It's a more dangerous approach but the way fill works it's a valid solution.

I'm not 100% comfortable with that and I'll take suggestions.

const secondContent = parts[2];

parts.splice(0, 2);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A comment noting why we're mutating here might be useful.

@josephfrazier
Copy link
Collaborator

This is a bit out of scope, but what if we used something like Immutable.js to allow us to avoid mutation without impacting performance (or with very little impact)? Obviously this would be a larger, separate change, but I wanted to throw it out there.

@suchipi
Copy link
Member

suchipi commented Nov 15, 2017

I think using immutable structures is a good idea to keep in mind... but adding it at this point seems excessive. Maybe if general performance concerns start to be more pressing, we should look into it.

@duailibe duailibe merged commit 8e5c335 into prettier:master Nov 16, 2017
@duailibe duailibe deleted the fill-slow-slice branch November 16, 2017 11:56
@vjeux
Copy link
Contributor

vjeux commented Nov 25, 2017

@josephfrazier immutable.js has a non trivial performance impact. In a React context, the performance overhead of the immutable data structures on-top of the js ones is offset by the wins you get from shouldComponentUpdate.

In our case, those data structures are pretty performance sensitive, so I'd be willing to be that we'll see a non trivial regression.

@suchipi suchipi added this to the 1.9 milestone Nov 28, 2017
@lock lock bot added the locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. label Jan 19, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants