Bonjour à tous !

Je viens de créer une petite application java qui, à partir d'un fichier xls me renvoie les données dans un csv et les en-têtes de colonnes ansi que diverses informations dans un fixhier xml.
Evidemment, je suis obligé d'utiliser une librairie. J'ai choisi poi.

Jusque là, tout va bien, mon appli fonctionne à merveille :D

J'ai donc buildé le tout, d'abord avec fat-jar (un module d'éclipse permettant d'inclure toutes les librairies dans l'exécutable). Mais ohh surprise, le temps d'éxécution qui dans éclipse était d'environ 7sec pour un fichier d'à peu près 1000 lignes * 250 colonnes passe à 30 secondes !

Je me suis alors dit, plugin de merde, retour au bon vieux classpath et la librairie dans le dossier lib. Re-surprise, il me faut alors 40 secondes pour extraire les données du même fichier !

Bon, je sais, mon algo n'est surement pas tip-top (je parcours les cellules par lignes et concatène les données dans un string) mais si je pouvais éviter de tripler le temps d'éxécution en créant un exécutable, ça m'arrangerais. Avez-vous une idée d'où vient le pb ??

Merci d'avance.

Laurent

Coucou , t as essayé de compiler ton jar avec des arguments du type -Xms512m ?

Il vaut mieu être riche et en bonne santé que pauvre et malade .

Non, je n'avais pas essayé, je viens donc de le faire et ça ne change rien :
java -Xmx512m -Xms32m -jar xls2csv.jar test.xls test.csv test.xml 35 sec

Après un petit tour sur google, il s'avère que ces arguments servent à augmenter la mémoire allouable quand un objet dépasse la taille maximum.

Or ce n'est pas mon cas. Ici, je n'ai pas d'erreur, juste une forte augmentation du temps d'éxécution.

Après optimisation, j'ai réussi à réduire un peu le nombre de boucles : je gagne 1 sec en exécution dans éclipse et 6 avec le jar !

Si quelqu'un sait comment récupérer les paramètres d'exécution dans eclipse pour lancer le jar de la même façon dans le terminal je suis prenneur. En attendant, je googlise :D

Bonne aprèm à tous

Il vaut mieux concaténer tes chaines de caractères avec un StringBuffer ou un StringBuilder, plutôt que de faire String = new String() + new String() + new String(); Parce qu'à chaque new String() il y a création d'un nouvel objet.

Merci du tuyau :D

Mais même si cela me permet de gagner encore tu temps d'exécution, ça ne résoud toujours pas mon pb de différence d'exécution entre eclipse et le terminal...

J'ai dit ça parce que sinon je n'ai aucune idée sur ton problème. Mais il m'intéresse, c'est au cas où quelqu'un trouve une solution.
y'aurait une option du genre "java -runAtSpeedOfLight -jar my.jar" ?

MDR
Ce serait bon ça

Mais bon, je pense que eclipse doit gérer par lui même des options lors du run, quelquechose qui optimiserait l'allocation de la mémoire ou un truc comme ça, j'en sais pas grand chose, tout ce que je constate c'est que dès que je lance mon appli via le terminal, il faut 5 fois plus de temps...
Et comme je débute en java et sous eclipse, ben je trouve pas où c'est...

Surtout qu'apparemment, mon appli est destinée à servir sur un projet de gestion de données où on doit pouvoir importer un dataset en xls de taille assez conséquente, le tout sur, me semble-t-il, un vieux serveur pourri. Donc si la version jar du truc met 40 secondes sur 1 P4 2GHz/1GoDDR pour un fichier de seulement 1000valeurs*250variables=250000 cellules, et pas 2000variables*10000valeurs, ça va pas le faire.

Merci quend même de t'intéresser à mon cas, je testerai le coup du StringBuffer dès lundi.

Personne n'a d'idée sur mon pb ??

Je viens de tout passer en String Buffer, tu avais raison, 2 secondes à l'exécution dans éclipse. Je suis plutôt satisfait.

Mais une fois compilé et exporté en jar, il m'en faut 25 ...

Attention pour vraiment gagner du temps, il faut choisir la bonne classe :

- environnement multithread où il est nécessaire de synchroniser l'accès aux données : StringBuffer
- environnement où il n'y a pas besoin de synchroniser les accès : StringBuilder

Le second choix est plus rapide mais ne fonctionnera pas en environnement synchronisé.

Je n'ai pas besoin de travailler en multithread.
Je ss donc passé au StringBuilder, ça ne change pas grand chose mais si c'est théoriquement plus rapide, je garde.
Avec tout ça, merci j'ai pu gagner pas mal de temps d'exécution dans eclipse (et apprendre pas mal de nouveaux trucs).
Mais je cherche toujours quelquechose pour en gagner à l'extérieur, parce que passer de 1.5 secondes dans éclipse à 20 dans le terminal, ça m'ennuie un peu, mais bon, si on peut pas faire autrement, je m'en passerai.