-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Better replacement for Artifact Indexes #106
Conversation
text/0106-artifact-indices.md
Outdated
- **pro**: Solves file decompression performance of Symbolicator. | ||
- **pro**: We _assume_ that most files inside of bundles are unused. | ||
- **pro**: We _assume_ that a lot of files will not change across bundles (polyfills, dependencies, etc). | ||
- **con**: We need a better way to store many small files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better in what way? Is it too expensive, too hard to organize, or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets see if @mitsuhiko wants to chime in here, as he was very vocal against doing this. I believe the reason is that depending on storage vendor, you are billed by number of files, which can get extremely expensive storing a ton of small files.
da3fcb9
to
6dae095
Compare
We want to come up with a way to support SourceMap processing or in particular access to files needed for SourceMap
processing that supports more customer use-cases, is correct, and is efficient to implement and scale.
Rendered RFC