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

speedup gx-go rw/uw #38

Merged
merged 4 commits into from
Jun 13, 2018
Merged

Conversation

Stebalien
Copy link
Collaborator

(10x)

Question: why did we use transitive dependencies when computing rewrites? IMO, we should definitely not be doing that. It's also slow.

@whyrusleeping
Copy link
Owner

Question: why did we use transitive dependencies when computing rewrites? IMO, we should definitely not be doing that. It's also slow.

So I don't have to explicitly import every single package that my dependencies import.

If we're going to make this change, we need to flag every time we encounter a dependency we don't have a mapping for.

@@ -107,13 +108,21 @@ func rewriteImportsInFile(fi string, rw func(string) string, rwLock *sync.Mutex)
return nil
}

offset := file.End()
for i, d := range file.Comments {
Copy link
Owner

Choose a reason for hiding this comment

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

what is this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Go ends up picking up an extra comment or two after the imports for some reason. Also, don't merge this yet. That commit appears to have broken something.

@Stebalien
Copy link
Collaborator Author

If we're going to make this change, we need to flag every time we encounter a dependency we don't have a mapping for.

I already assumed this was a bug and fixed cases like this everywhere I found them.

So I don't have to explicitly import every single package that my dependencies import.

It just feels a bit implicit. Also, it's probably a bit bug prone: we can (and unfortunately often do) import multiple copies of the same dependency. In this case, gx-go will just choose one.make

@Stebalien
Copy link
Collaborator Author

If we're going to make this change, we need to flag every time we encounter a dependency we don't have a mapping for.

Ah, you mean in the code? Yes, we will. Also, it appears that we have some packages we'll have to fix.

@Stebalien
Copy link
Collaborator Author

Mmm. 50x faster. Unfortunately, you were right about the transitive dependency issue so I'll have to fix those first.

@whyrusleeping
Copy link
Owner

I kinda intended it as a feature initially. Makes it so if i import foo that uses bar, I don't have to explicitly import bar to pass a bar.Cat to foo.GetAnimalNoise

@Stebalien
Copy link
Collaborator Author

I get that, but its leaky. Even changing an internal dependency will break something. However, for now, I'll add that back. I still get a nice speedup by memoizing package.json files instead of reparsing them.

@Stebalien
Copy link
Collaborator Author

So, really, finding rewrites recursively wasn't the performance issue. The performance issue was re-traversing parts of the DAG.

@whyrusleeping this should work now.

@Stebalien
Copy link
Collaborator Author

This also appears to reduce a fresh gx install in go-ipfs from a minute to 2 seconds.

@whyrusleeping
Copy link
Owner

Okay, so we're switching to only rewriting the imports here. That sounds great to me. This whole bit with writing to a buffer multiple times, then writing to a temp file and then moving it over the top of the original seems a bit hectic... but it works, and its fast as hell now. 👍 here

@whyrusleeping whyrusleeping merged commit 6756151 into whyrusleeping:master Jun 13, 2018
@Stebalien
Copy link
Collaborator Author

This whole bit with writing to a buffer multiple times, then writing to a temp file and then moving it over the top of the original seems a bit hectic...

I really tried to simplify that but the go formatter/parsers just weren't having it. I wish there were a "See this AST I just modified? Fix the positions for me.".

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

Successfully merging this pull request may close these issues.

2 participants