Improve struct dictionary codecs in Go
Los mantenedores suelen responder en 1 día
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
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- go
- Área
- performance
Línea de trabajo
Start by reviewing the Go struct and dictionary codec implementation and the initial experiment in the linked profileserialize branch. Work through the unchecked Tree-to-hashmap item alongside the completed freezing, pointer-reference, CopyFrom, and refNum goals. Done means the remaining dictionary-encoded struct copying is reduced without breaking the listed behaviors.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
We do a lot of unnecessary copying and cloning of dictionary-encoded structs currently, especially during encoding.
Consider the following:
- Allow marking structs frozen. Once frozen they can be safely referenced by pointer from multiple places (including dictionaries) without cloning.
- Use freezing after record is read.
- Allowing referencing frozen structs from read operations directly in write operations. Should improve copying (read/write).
- Make CopyFrom smarter, avoid cloning frozen structs, just copy the pointer.
- Encourage Freeze() when creating data (not from Read()) of Writer. Should improve encoding.
- Cache refNum in the object to avoid slow Tree lookups.
- Replace Tree by Hashmap. Cache the hashcode, invalidate on modifications.
- Allowing setting dictionary structs in their containing structs by pointer instead of requiring full CopyFrom or field-by-field setting.
Most of these can be applied to varying degrees both to Go and Java. This summary issue is for Go. Duplicate it for Java.
See some initial experiment on this branch https://github.com/splunk/stef/compare/main...tigran/profileserialize?expand=1
- Lenguaje dominante
- Java
- Estrellas
- 12
- Forks
- 6
- Merge medio
- 4 h 45 min
- PR fusionados (30 d)
- 9
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
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 splunk/stef
-
bug Go
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
bug Go help wanted
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
Los mantenedores suelen responder en 1 día
-
Finalize generated Go APIAbiertoGo
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
splunk/stef#285 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de splunk/stef
Issues similares
-
5.0.x backport enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
spring-cloud/spring-cloud-function#1507 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
open-learning-exchange/myplanet#18484 ·
Los mantenedores suelen responder en 1 día
-
ai-driven-fuzzing bug claude Minor
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
linagora/twake-calendar-side-service#1417 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
line/armeria#7109 · 3 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
open-feature/java-sdk-contrib#1966 ·
Los mantenedores suelen responder en 1 día