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

Reduce overhead of read_data and write_data

Abierto
#202 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
numpy, python
Área
api, performance

Línea de trabajo

Comienza por los puntos de entrada de los bindings de Python read_data y write_data, usando el hilo de Discourse enlazado para comprender la sobrecarga reportada y las notas sobre reshape, asignaciones y comprobación de errores. Compara las mediciones de tiempo del lado de Python con las mediciones de tiempo de preCICE y, después, verifica que las funciones conserven su comportamiento evitando al mismo tiempo copias y asignaciones innecesarias.

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

Descripción

In this discourse thread, I tracked down the increased duration spent in the "do-nothing solver" down to read_data and write_data.

Most logical explanation would be the additional

  • input vertex_ids and values are copied to a vector, even though passing np.reshape(X, -1) to the preCICE API suffices and prevents copies.
  • output values are allocated, then passed to the API, then allocated to build an np.array
  • we do a lot of additional error checking (which is good)

Example of rhoVW on solver2, being vectorial data of large mesh:

  • Time measured in preCICE: 7ms (note: this doesn't allocate)
  • Time measured in Python: 40ms (including overhead from activating profiling in python, this needs to allocate, so overhead scales with size)

Notes:

  • With some tweaking I can get this down to 30ms. This makes the function actually shorter, simpler, and easier to follow.
  • np.flatten() copies the input, while np.reshape doesn't if it can avoid it.
  • The majority of the generated code seems to be error handling, which we could potentially be avoided by using the CPP API directly for calls to getDataDimensions and do this in one place.
  • This overhead could be profiled with something like https://github.com/precice/precice/issues/1647
Lenguaje dominante
Cython
Estrellas
30
Forks
19
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

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 precice/python-bindings

Todos los issues de precice/python-bindings

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.