performance problems with large filewatch objects
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 10.1k
- Forks
- 413
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 6
Description
Repro Steps
- Create a Tiltfile in a go project with lots of dependencies
- Run
go mod vendor
Current Behavior
tilt creates a very large FileWatch object in-memory
this slows down all operations, e.g.,
time tilt get filewatch -o yaml | tail -n 3
kind: List
metadata:
resourceVersion: ""
real 0m0.729s
user 0m0.763s
sys 0m0.071s
even though all the data in the filewatch is never used
We should try to consolidate that data.
Additional context
Probably the simplest way to do this would be to add a new field, like "DirectoriesChanged", for consolidating lots of FilesChanged in a single directory.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue in a Go project by creating a Tiltfile with many dependencies and running go mod vendor, then inspect the FileWatch data exposed by tilt get filewatch -o yaml. Determine how the large collection of file changes can be consolidated without losing needed data; done means the object is substantially smaller and the reported operations are faster.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- devtools, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100