Perf - Add buffer pooling where relevant
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- csharp
- Área
- performance
Línea de trabajo
Revisa InflaterInputStream y las clases de compresión relacionadas que asignan buffers en sus constructores; compara las alternativas propuestas caller-supplied-buffer y ArrayPool. Define el alcance, la propiedad de los buffers y el comportamiento de liberación antes de la implementación; después, valida que una compresión intensiva reduzca la presión de asignaciones sin cambiar el comportamiento del stream.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Current situation
Some pieces of code such as InflaterInputStream, through InflaterInputStream, allocate buffers upfront in their constructors, with no way to control this behavior (e.g : passing the buffer to use).
In code making intensive use of such classes (e.g : app sending huge amounts of compressed data in my case), this can result in this being unsustainable in term of resulting GC load.
Describe the solution you'd like
I would like to suggest some alternatives :
- add constructors overload admitting the buffer to use (so client can handle the reuse logic)
- use
ArrayPoolall the time, this is choice taken by Microsoft inDeflateStream. While it allocates a new buffer on Net Fx (https://referencesource.microsoft.com/#System/sys/System/IO/compression/DeflateStream.cs,63), on Net Core it is always retrieved from theSharedpool and returned when the stream is disposed (https://source.dot.net/#System.IO.Compression/System/IO/Compression/DeflateZLib/DeflateStream.cs,109) - any mix of the two previous solutions.
Describe alternatives you've considered
Due to current design of most classes there is sadly no alternative as there is no control over the buffers allocations in constructors.
Tags
Performance
- Lenguaje dominante
- C#
- Estrellas
- 3.9k
- Forks
- 1k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de icsharpcode/SharpZipLib
-
*no response* bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
icsharpcode/SharpZipLib#905 · 1 comentario ·
-
bug bzip2
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
icsharpcode/SharpZipLib#904 ·
-
SetLevel in ZipFileAbiertoenhancement zip
Dificultad 2/5 1-2 días Aptitud para principiantes 55/100
icsharpcode/SharpZipLib#903 ·
-
*no response* bug
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
icsharpcode/SharpZipLib#901 · 1 comentario ·
-
*no response* bug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
icsharpcode/SharpZipLib#894 · 1 comentario ·
Todos los issues de icsharpcode/SharpZipLib
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
microsoft/fluentui-blazor#5364 ·
Los mantenedores suelen responder en 1 día
-
.NET triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
microsoft/agent-framework#8811 ·
Los mantenedores suelen responder en 1 día
-
.NET Docs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
getsentry/sentry-dotnet#5637 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
QuantConnect/Lean#9842 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
NethermindEth/nethermind#14012 ·
Los mantenedores suelen responder en 1 día