Quelle catastrophe ! Nous souhaitons utiliser pour la première fois la fonction xlsOuvre avec un fichier qui contient énormément de données. En soi, le fichier est assez léger : il s’agit d’un document “.xlsx” de 14.022 Ko. Celui-ci contient 7 colonnes, et 82.348 lignes. Plusieurs fonctions sont utilisées (arrondi, somme, etc…)

En tentant notre chance une première fois pour ouvrir le fichier Excel en stockant le résultat dans une variable xlsDocument, cela a carrément planté le programme : il est arrivé à 1,8 Go de mémoire RAM consommés, après 3 à 5 secondes, et a mis à genoux le programme. Ce dernier était littéralement bloqué, et occupait également 25 % de l’UC.

La seconde fois, nous avons stocké le résultat dans un entier, comme le permet la fonction. En effet, on récupère dans ce cas un handle qu’on peut manipuler avec le reste des fonctions xls*. Le résultat est (presque) identique mais a toutefois permis d’ouvrir le fichier. La mémoire a grimpé jusqu’à 1,1 Go après 3 à 5 secondes, et le fichier s’est ensuite chargé très (très) lentement, pour arriver à une consommation de 1,5 Go. Nous avons ensuite pu récupérer les premières données. On peut donc constater que dans ce cas, la mémoire requise est légèrement inférieure. Malheureusement, cela reste de trop… Obligation de découper le fichier en plusieurs parties plus petites.

Le test a été effectué sur une machine Intel Core i3 370M, 3 Go de mémoire DDR2, Windows 7 x86 SP1. La mémoire n’a pas été libérée après cette opération. Il faut idéalement attendre l’exécution de xlsFerme pour cela.

A première vue, ce bug avait déjà été remonté pour les versions précédentes de WinDev, puisque des utilisateurs avaient également abordé ce souci.

Espérons que PC SOFT prenne enfin ces remarques en considération afin d’améliorer les performances, actuellement désastreuses, de cette fonction. Pour vous dépanner, nous vous recommandons de convertir votre document au format CSV puis d’utiliser les fonctions de gestion des fichiers (fOuvre, fFerme, fLit, etc).