Comment by Didier Vibert on 2023-10-20 09:12:02:

la conversion simple implique 2 copies

en creusant un peu, la solution d'abandonner les wrapper et de passer par la simple conversion a l'inconvénient de génèrer 2 copies...

<pre>
std::vector -[swig std_vector.i]> python tuple --[python api]-> numpy array
</pre>

l'implémentation actuelle, aucune copie, MAIS...

<pre>
std::vector -[swig numpy.i (Argout View Arrays)]-> numpy array (même buffer que celui du std::vector)
</pre>
ne génère aucune copie si on passe l'adresse du buffer du std::vector mais pose alors le problème de durée de vie du buffer (cf "Argout View Arrays":https://numpy.org/doc/stable/reference/swig.interface-file.html#argout-view-arrays)

> There is almost no way to guarantee that the internal data from the C code will remain in existence for the entire lifetime of the NumPy array that encapsulates it. If the user destroys the object that provides the view of the data before destroying the NumPy array, then using that array may result in bad memory references or segmentation faults. Nevertheless, there are situations, working with large data sets, where you simply have no other choice.

Avec cette solution on peut à la place allouer dans le wrapper et copier le contenu, dans ce cas plus de risque de destruction intempestive du buffer, mais une fuite mémoire, car la desallocation du nouveau buffer ne sera jamais faite.

Alternative, avec une copie

Il y a une autre possibilité, qui génère une seule copie au lieu de deux, en modifiant le wrapper actuel, toujours via numpy.i mais en utilisant cette fois des "Memory Managed Argout View Arrays":https://numpy.org/doc/stable/reference/swig.interface-file.html#memory-managed-argout-view-arrays :
<pre>
std::vector -[swig numpy.i (Memory Managed Argout View Arrays)]-> numpy array (buffer alloué par le wrapper, désalloué par le code python à la disparition du numpy array)
</pre>

(cf https://scipy-cookbook.readthedocs.io/items/SWIG_Memory_Deallocation.html)

L'utilisation des "Memory Managed Argout View Arrays" permet de transférer à python le contenu d'un std::vector dont on ne connait pas la taille à l'avance, et dont pyhon va manager la desallocation (il faut alors allouer et copier le contenu du std::vector dans le wrapper c++)

Note: On peut aussi arriver au même résultat en utilisant des "Argout Arrays":https://numpy.org/doc/stable/reference/swig.interface-file.html#argout-arrays mais dans ce cas, lors de l'appel python pour retourner le tableau, il faut passer en argument la taille du tableau retourné (pour que swig alloue un numpy array de la bonne taille avant):
<pre><code class="python">
myarray = PC.Get_Float64Array(binded_vector, known_size)
</code></pre>
ce qui est moins "pythonic" mais faisable dans notre cas car nous voulons des getter sur des vecteurs déjà construits et dont on peut connaitre la taille en exportant une fonction qui la retourne.

Alternative sans copies

pas trouvé sans avoir de problèmes de memory management.

Comment by Ali Allaoui on 2023-10-20 09:14:23:
On ne fait pas ça un moment critique point de vue mémoire ou performance, donc de mon point de vue ce n'est pas grave de faire deux copies

Comment by Didier Vibert on 2023-10-20 09:26:16:
Ali Allaoui wrote in #note-2:
> On ne fait pas ça un moment critique point de vue mémoire ou performance, donc de mon point de vue ce n'est pas grave de faire deux copies

c'est pas faux, aujourd'hui.

De toute façon il faut modifier le code dans un sens ou dans l'autre, et ce n'est bien compliqué d'implémenter la version économe avec ce qu'on a déjà (pas de modif du code python, une allocation et copie à ajouter dans les fonctions de pyconv.h, et la déclaration modifiée pour passer des memory managed argout view arrays dans redshift.i)

Comment by Didier Vibert on 2023-10-27 13:12:59:
finalement j'ai implémenté la conversion vector -> numpy
qui gagne un peu en vitesse et en mémoire

Comment by Pierre-yves Chabaud on 2023-11-10 15:17:23:
Merged into @develop@ (@8e65b718@)