Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Low-overhead statistical sampling mode

Abierto
  • ¿Algo no está bien?
#6 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
c, python
Área
devtools, performance

Línea de trabajo

El issue no menciona archivos, pruebas ni puntos de entrada. Empieza localizando el type collector existente y la ruta del profiling hook, y luego compara la recopilación de referencia con un intervalo de muestreo configurable. Se considera completado cuando la tasa de muestreo se puede controlar, la sobrecarga en producción se puede medir cerca del objetivo indicado y los tipos recopilados siguen siendo útiles; la agregación entre procesos queda fuera del alcance.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Currently collecting types has a significant performance impact, and even rewriting type collection in C/Cython would only reduce it so much. It would be nice if the performance impact would be controllable in a way that the lower end would be, say, 1-2%. This would make it practical to collect types on production servers.

The motivation is that types collected during tests or manually running a program are unlikely to be complete, and during tests it's possible to have mocks and fakes that generate noise. By running in production on a large number of servers, it may be possible to easily collect a fairly complete picture of concrete runtime types, at least for more commonly used functions.

A potential approach is to run the type collector for roughly every N call events. At least the sampling logic would have to be implemented in C (or maybe Cython?) for acceptable performance. If N is large enough, the overhead would be dominated by the cost of invoking the profiling hook + a few machine instructions to decrement a counter and check the value.

It should be easy to validate the performance impact of the approach. The cost of collecting types isn't very important since we can make N large. However, at some point the collected types will be too sparse to be useful.

This issue doesn't cover how we'd aggregate types collected in multiple processes.

(The proposed approach is not my invention.)

Lenguaje dominante
Python
Estrellas
1.4k
Forks
59
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dropbox/pyannotate

Todos los issues de dropbox/pyannotate

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.