Conversation
It looks like maintainers aren't very active on the repo and nytimes/gziphandler#107 has come to a standstill. I don't want to wait forever for this to go in. Let's use a replace directive to point to the fork. When the PR gets merged, we can just bump the dependency and remove the replace directive. Re: the PR, copying the text from the PR description This gives 40-50% improvements in CPU with very minor increase in memory, just as a drop-in replacement. I think that is a very reasonable tradeoff. The library is mature and safe to be used in production. ``` name old time/op new time/op delta GzipHandler_S2k-8 74.9µs ± 2% 34.4µs ± 2% -54.07% (p=0.000 n=10+9) GzipHandler_S20k-8 379µs ± 1% 226µs ± 3% -40.42% (p=0.000 n=9+10) GzipHandler_S100k-8 1.95ms ± 2% 1.15ms ± 1% -41.27% (p=0.000 n=9+9) GzipHandler_P2k-8 24.3µs ±25% 10.7µs ±25% -55.80% (p=0.000 n=10+10) GzipHandler_P20k-8 132µs ± 2% 75µs ± 1% -42.95% (p=0.000 n=9+10) GzipHandler_P100k-8 658µs ± 2% 371µs ± 3% -43.68% (p=0.000 n=9+10) name old alloc/op new alloc/op delta GzipHandler_S2k-8 7.71kB ± 5% 9.13kB ± 7% +18.33% (p=0.000 n=10+10) GzipHandler_S20k-8 65.1kB ± 3% 70.3kB ± 3% +8.05% (p=0.000 n=10+10) GzipHandler_S100k-8 348kB ± 4% 382kB ± 2% +9.85% (p=0.000 n=10+10) GzipHandler_P2k-8 7.60kB ± 1% 7.93kB ± 2% +4.33% (p=0.000 n=10+10) GzipHandler_P20k-8 64.4kB ± 1% 66.3kB ± 2% +2.92% (p=0.000 n=10+10) GzipHandler_P100k-8 304kB ± 1% 309kB ± 1% +1.67% (p=0.000 n=10+9) name old allocs/op new allocs/op delta GzipHandler_S2k-8 21.0 ± 0% 21.0 ± 0% ~ (all equal) GzipHandler_S20k-8 24.0 ± 0% 24.0 ± 0% ~ (all equal) GzipHandler_S100k-8 27.0 ± 0% 27.0 ± 0% ~ (all equal) GzipHandler_P2k-8 21.0 ± 0% 21.0 ± 0% ~ (all equal) GzipHandler_P20k-8 24.0 ± 0% 24.0 ± 0% ~ (all equal) GzipHandler_P100k-8 26.0 ± 0% 26.0 ± 0% ~ (all equal) ``` https://mattermost.atlassian.net/browse/MM-28491
streamer45
left a comment
There was a problem hiding this comment.
Given the simplicity of the implementation and the fact that the upstream has been idle for almost a year can't we just host our own version like we do for other things (e.g. gorp, viper)?
This is to avoid going through the same process in case we need additional changes in the future.
|
Hmm .. yeah let's keep it under my username for now. If there are more changes, we can move it under mattermost. |
|
@lindalumitchell - can be qa-deferred. |
|
Testing mattermod. Please ignore. /cherry-pick release-5.27 |
|
Cherry pick is scheduled. |
|
Error trying doing the automated Cherry picking. Please do this manually |
|
/cherry-pick release-5.27 |
|
Cherry pick is scheduled. |
|
Error trying doing the automated Cherry picking. Please do this manually |
It looks like maintainers aren't very active on the repo
and nytimes/gziphandler#107 has come to a standstill.
I don't want to wait forever for this to go in. Let's use a replace directive
to point to the fork. When the PR gets merged, we can just bump the dependency
and remove the replace directive.
Re: the PR, copying the text from the PR description
This gives 40-50% improvements in CPU with very minor increase
in memory, just as a drop-in replacement. I think that is a very reasonable tradeoff.
The library is mature and safe to be used in production.
https://mattermost.atlassian.net/browse/MM-28491