Optimisation code Java

Bonjour à tous,
Je me suis inspiré d'une application développée en VB pour faire une autre application en Java. Ces deux applications font absolument les mêmes choses, tournent sur des postes client en local toutes les deux, donnent les mêmes résultats (des statistiques sur des listes de discussion), sauf que celle en VB le fait en 5 minutes, et la mienne (en Java) en 3 heures !
J'ai chronométré les différents processus de mon appli mais je n'arrive pas bien à voir où et pourquoi j'ai des temps de calcul aussi long.
D'où mes questions :
- je me sers d'h2 pour la base de données : est-ce la plus rapide ?
- certaines requêtes comme les "update" ou les "select" sont super longs
- j'avais entendu des trucs sur la boucle for : comme j'en utilise plein, est-ce que cela peut ralentir mon application ? si oui, qu'utiliser ?
- vaut-il mieux faire des requêtes sur une bdd ou écrire dans des fichiers (j'ai l'impression que ce dernier prend moins de temps!!)
- quel est le plus rapide dans la création/lecture/accession/manipulation entre un ArrayList, un tableau normal, un hashset, un tableau chaîné (même si je sais que tous ces tableaux sont très particuliers et réservés à des utilisations précises, je ne sais jamais lequel choisir lorsque ce que j'ai à faire dessus les concerne tous !!)
- lorsqu'on a un long traitement à faire, vaut-il mieux séparer les processus le plus possible (faire plein de void qu'on appelle d'une classe principale) ou faire un gros void énorme ?
- dans le même ordre d'idées, faut-il cloisonner ou décloisonner son programme, faire plein de classes très courtes, ou peu de classes très longues ?

Donc voilà, en gros, je me demande comment on optimise son code JAVA (hors algo car c'est un autre problème !) ???!!!
Merci à tous de vos nombreuses aides et réponses et orientations !

mc

Citation:

---

je me demande comment on optimise son code JAVA (hors algo car c'est un autre problème !)

---

C'est là que tu as tout faux : d'abord on reflechit à son code, on apprends l'algo, et ENSUITE on optimise.

Pour te donner un ordre d'idée : passer de 0,2 sec à 0,05 sec est une optimisation, 3h au lieu de 5 minutes, c'est un mauvais code.

Cherche sur internet les bonnes pratiques de la programmation, les bases d'algorithmique et les bases du sql.

Si après tu veux des conseils plus 'pratique', poste une partie de ton code pour qu'on puisse le commenter.

Salut,

Si tu es sous eclipse, je te suggère d'installer les plugins checkstyle/pmd qui permettent de contrôler ton code (lisibilité, performances...), qui pourront te permettre de repérer des éventuelles bourdes dans ton code (genre des variables déclarés dans des boucles, un appel de fonction pour définir le nombre d'itérations dans une boucle for, ...) mais bon, à moins que ton programme se résume à une boucle exécutée 300000 fois, ça risque de pas être vraiment significatif...

Autre plugin sympa qui peut t'aider(que je maitrise po tout à fait ^^), c'est TPTP
C'est un plugin qui te permet de voir à la fin de ton programme quels ont étés les traitement les plus consommateurs de temps, les appels de fonctions qu'il y a eu, etc....
Bref, moi ça m'a permit de trouver dans le code un Reader que j'ai remplacé par un BufferedReader, et vu qu'il y avait 100000 lectures dessus, j'ai divisé le temps d'exécution par 2 !

Bon courage pour ton optim et tiens nous au courant !

Je pense que ton portage en java n'est pas top dû a ton expérience dans ce langage.
pour passer de 2h a 5minutes faut faire un très grand ménage dans ton code :)
Montre nous la partie qui consomme le plus de temps, on essayera de voir ce qu'on pourra faire.
A++

Salut
Faiche : oui tout à fait, il y a de gros soucis d'algo à mon avis aussi, mais quand on traite 30000 lignes dans une base de données, l'optimisation peut entrer en jeu aussi non ?
Legentil : merci, je vais regarder ça de plus près
Hibour : le souci c'est que je ne connais absolument pas les algos du soft en VB, sinon tu penses bien que je les aurais repris !

A tous : je suis très conscient d'avoir des soucis d'algo et je vais reprendre tout ça, mais y-a-t'il aussi des trucs vraiment à éviter (boucle for, bdd h2 ... etc) ?

@+

Je pensai que t'avais le code source VBA sous les yeux.
Comme ca on ne pourra pas t'aider sans code!

Si tu fais de l'i/o, est ce que tu utilises les buffers ?

Est ce que t'es sur que les traitements ne sont pas parallélisés dans la version VB ?

Pour calculer la complexité de tes boucles, c'est simple : plus elles sont imbriquées, plus elles prendront de temps.

30000 lignes dans une base, c'est rien. Mais après ça dépend de ton niveau en SQL. Si tu as un doute, tu poses la question sur ta requete et ton schéma sur le forum correspondant. J'ai vu des applis qui mettaient 25 minutes à mal faire ce qu'une requete bien faite aurai mis 0,25 secondes à bien faire.

La différence entre "un gros void" et "plusieurs petits void" c'est une question de conception. On ne met pas tout dans la meme classe. Une classe doit faire une chose, pas plusieurs, mais ça n'influe pas sur les performances.
(Je passe sur les gros et petits void, ça ne veut rien dire, mais on comprends l'idée.)

Si tu fais beaucoup de concaténations de chaine (String) regarde les cours, pour savoir quand utiliser + et quand utiliser StringBuilder.

pour l'instant c'est tout ce que je vois.

Le SQL peut également jouer un grand rôle dans l'affaire...
Attention à l'exécution des requêtes, aux commit etc.

Citation:

---

Envoyé par maccormick

A tous : je suis très conscient d'avoir des soucis d'algo et je vais reprendre tout ça, mais y-a-t'il aussi des trucs vraiment à éviter (boucle for, bdd h2 ... etc) ?

---

Ben cherche pas alors, apprends ce qu'est une estimation du temps de calcul d'un programme simple (dans un langage quelconque, l'algorithmique n'est pas dépendante d'un langage...). Ensuite tu comprendras pourquoi ton code est lent :)

A savoir que ce qui prends du temps dans tout programme en général, ceux sont les opération d'entrées/sorties : les limiter tu dois ! (:P).

Bon courage ;)

je plusoie les gens qui te disent de checker ton SQL. On peut traiter 30.000 lignes sql en quelques millisecondes avec un bon SGDB. Par contre si on commence à faire soi même le boulot du SGBD c'est la cata, et c'est là que pêchent les débutants. Par exemple faire une boucle for sur les 30.000 ligne pour trouver la ligne à modifier et la modifier au lieu de faire un update ... where ..... Ce qui plombe dans ces cas, dans 99% du temps c'est que tu force le SGDB à sortir tous les résultat pour en jeter à la poubele 99.9% alors que tu pourrais lui demander de juste sortir le résultat qui t'intéresse.

Maintenant, sans les bout de code, l'algo, les requetes SQL, on ne fait que conjecturer dans le brouillard total.

Bonsoir,

Je confirme la mauvaise utilisation des SGBD de certains. J'ai moi même "amélioré" un programme en fournissant un simple buffer pour ne faire que deux requêtes avant et après les calculs. D'un point de vue performances, le gain (rapport entre le temps mis avant et après) est proche du million.

Utilisez donc la RAM messieurs, les derniers ordinateurs nous en proposent au moins 2Go (et encore pour des bas de gamme), c'est bien assez pour toutes vos folies ;)

Citation:

---

Envoyé par Faiche

La différence entre "un gros void" et "plusieurs petits void" c'est une question de conception. On ne met pas tout dans la meme classe. Une classe doit faire une chose, pas plusieurs, mais ça n'influe pas sur les performances.
(Je passe sur les gros et petits void, ça ne veut rien dire, mais on comprends l'idée.)

---

Il y a quand même un prix à l'utilisation de beaucoup de classes et de plein de petites méthodes, les invocations successives. Dans le cas présent, ça ne doit pas du tout jouer, mais ça peut être un facteur d'optimisation (avec l'inlining).

Sur le cas présent : tu utilises les même procédures / requêtes SQL que le code VB ? Si oui, on peut penser que le problème ne vient pas de là. Si non, on peut supposer qu'il vient de là :)

Claythest : merci pour "limiter les opération d'entrées/sorties" mais qu'entends-tu par là exactement ? les requêtes à la bdd ?
Pour les autres : merci beaucoup pour toutes vos idées et commentaires, surtout sur le SQL (merci tchize_, effectivement, c'est la bonne façon de raisonner !) . Oui bien sûr, j'ai un gros problème d'algo, et je suis en train de le régler ...
Mais je ne suis pas un débutant, plutôt un débutant confirmé :zoubi:, et ma question ne portait pas sur un problème particulier (c'est pour ça que je ne vous donne aucune source) mais sur la question plus générale des choix qu'on a à faire à certains moments ... enfin je le pensais, car justement, ce que vous m'avez appris, ou plutôt confirmé, c'est que l'algorithme est ce qu'il y a de plus important ... enfin je le savais mais dans mon projet actuel, je développe pendant 2 semaines, je fais autre chose pendant 2 mois (je suis statisticien), je redéveloppe pendant 1 semaine, je refais autre chose pendant 3 mois ... etc, donc c'est un peu dur d'avoir une vision d'ensemble à chaque fois ... du coup je me retrouve avec une super appli, mais qui tourne super lentement parce que je fais les choses 10 fois au lieu de les faire 1 seule fois et que je développe à la bourrin !!! donc quand je parlai d'optimisation, c'était pour demander si il n'y avait pas quelques pièges grossiers à éviter ...
@+

le piège à éviter, sous toutes ses formes, c'est de mettre une ligne de code anodine dans une boucle important sans se rendre compte que cette ligne cache un code très lent. On a l'exemple en SGDB (mettre un requete SQL dans un grosse boucle, mauvais plan, une requete SQL implique un algo de recherche sur le sgdb, implique une transmission de données etc), mais ce n'est pas restreint à ca. Ca pourrait etre un appel répétitif à un getMachin(), en oubliant que getMachin va ouvrir un fichier pour le lire et en extraire la valeur, par exemple, ou en oubliant que getMachin va devoir faire un gros calcul car c'est une valeur synthétique ;) Ou encore getMachin alloue beaucoup de mémoire pour la rendre au Garbage collector juste après. Ou getMachin est synchronized. Etc ;)


Mais ca fini tous par nous arriver, et quand ca arrive, soit on trouve assez vite avec un peu d'analyse de code, soit si on y passe plus d'une demi heure à trouver, on utilise un profiler qui nous donnera les "point chaud" de notre code.

Citation:

---

Envoyé par Rei Ichido

Il y a quand même un prix à l'utilisation de beaucoup de classes et de plein de petites méthodes, les invocations successives. Dans le cas présent, ça ne doit pas du tout jouer, mais ça peut être un facteur d'optimisation (avec l'inlining).

---

Pense à tous les architectes et chef de projets à qui tu viens de faire verser une larme en écrivant ça.

Les appels imbriqués coûtent 0.

Des "grosses" classes qui contiennent tout limitent la testabilité, la réutilisabilité, la lisibilité et la maintenabilité. C'est une très TRÈS mauvaise pratique.

Le seul environnement dans lequel tu auras besoin de pousser l'optimisation à ce point, c'est dans les systèmes temps réel, en C, et avant d'en arriver là, il y a facile un million de trucs à prendre en compte avant.

Citation:

---

Envoyé par Faiche

Pense à tous les architectes et chef de projets à qui tu viens de faire verser une larme en écrivant ça.

Les appels imbriqués coûtent 0.

---

Si seulement :?
Hélas, quand on appelle une méthode ça a un coût, et qui peut devenir important sur des boucles importantes et des appels d'appels ... Notamment parce que les méthodes utilisées sont déterminées au runtime, polymorphisme oblige.

Citation:

---

Des "grosses" classes qui contiennent tout limitent la testabilité, la réutilisabilité, la lisibilité et la maintenabilité. C'est une très TRÈS mauvaise pratique.

---

Là on parle d'autre chose, et je ne te contredirait certainement pas ! Mais il faut bien avoir conscience que ça peut nuire aux performances. Sur la plupart des applis, ça ne sera pas grave du tout, et l'impératif de maintenabilité prime. Mais de temps en temps, ça peut valoir le coup de réduire un peu la voilure.

Citation:

---

Envoyé par Rei Ichido

Si seulement :?
Hélas, quand on appelle une méthode ça a un coût, et qui peut devenir important sur des boucles importantes et des appels d'appels ... Notamment parce que les méthodes utilisées sont déterminées au runtime, polymorphisme oblige

---

C'est vrai et c'est faux à la fois, désolé pour toi :)

En théorie, ça a un cout qui peut être pénalisant, puisque le late binding de java oblige d'aller sur la table des méthodes retrouver l'addresse réelle de la méthode concernée (au même principe que les méthode virtual de C++)

En pratique, ce cout est négligable pour plusieurs raison:

Si l'appel est peu fréquent, il n'est pas dans la zone "gros mangeur" de ton application, et vouloir retirer ca c'est comme vouloir éviter à ta bassine 50Lde déborder en retirant une petit cuiller d'eau.

Si l'appel est fréquent, il fera partie des zone qui seront compilée par le compilateur jit de java. Et ce compilateur a les particularités suivante:

1) il hardcode les adresse de mémoire la pluspart du temps, et sans erreur. Comme il tourne "runtime", il est certains de ce qu'il fait et pas limité par les contraintes qu'a le compilateur
2) il peut lui même et le fait très souvent inliner une methode dans une autre, ca dépend de l'opportunité de le faire ou non et de deux trois autres condition.

Alors oui un appel dynamique de méthode prend du temps, non tous les appel de méthode dynamique au sens du compilateur ne sont pas nécessairement des appels de méthode au sens de la machine destination.

Ce code chez moi, par exemple, met 6294ms à s'exécuter lors du premier appel. Lors du deuxième appel, le compilateur jit entre en jeu, je passe à 3773ms. Le code équivalent en inline met 3520ms la premier fois et 3475 la seconde, le jit a très peu de marge de manoeuvre.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

public int boucle1() { int a = 0; for (int i = 0; i < 50000; i++) { a ^= boucle2(i); } return a; }   public int boucle2(int input) { int b = 0; for (int j = 0; j < 100000; j++) { b += input | j; } return b; }     /**      * @param args the command line arguments      */ public static void main(String[] args) { while (true) { long debut; long fin; Main main = new Main(); debut = System.currentTimeMillis(); int a = 0; for (int i = 0; i < 50000; i++) { int b = 0; for (int j = 0; j < 100000; j++) { b += (i | j); } a ^= b; } fin = System.currentTimeMillis();   System.out.println("direct: " + a + "-> " + (fin - debut)); debut = System.currentTimeMillis(); a = main.boucle1(); fin = System.currentTimeMillis(); System.out.println("method: " + a + "-> " + (fin - debut)); }

---

j'obtiens ce genre de sortie

Code:

---

1 2 3 4 5 6 7 8

direct: -951285504-> 3520 method: -951285504-> 6294 direct: -951285504-> 3475 method: -951285504-> 3773 direct: -951285504-> 3449 method: -951285504-> 3768 direct: -951285504-> 3447 method: -951285504-> 3767

---

il reste un coût des méthodes, mais qui est du, je pense, là à l'algo de calcul utilisé pour mon exemple. Des boucles imbriquée permettent d'optimiser au niveau compilateur l'utilisation des registres, ce qui n'est pas le cas avec l'inlining des méthodes je suppose. Avec des calculs plus complexes, la différence s'estomperais encore plus.

De toute facons entre la prise de tête de maintenir de grosses méthodes et le coût d'un CPU, il vaut mieux pour ce cas là, acheter un cpu un peu plus gros que de se lancer à fonds perdu dans le l'optimisation aux résultats hasardeux.

Citation:

---

Envoyé par tchize_

il reste un coût des méthodes, mais qui est du, je pense, là à l'algo de calcul utilisé pour mon exemple. Des boucles imbriquée permettent d'optimiser au niveau compilateur l'utilisation des registres, ce qui n'est pas le cas avec l'inlining des méthodes je suppose. Avec des calculs plus complexes, la différence s'estomperais encore plus.

---

Ca laisse 10%, ce qui est pas négligeable ! Mais j'avoue que je ne pensais pas le jit aussi performant. La 1ère passe reste sur du simple au double. Mais sur le fond, ok, je note, et je m'endormirai moins bête ce soir :mrgreen:

Citation:

---

De toute facons entre la prise de tête de maintenir de grosses méthodes et le coût d'un CPU, il vaut mieux pour ce cas là, acheter un cpu un peu plus gros que de se lancer à fonds perdu dans le l'optimisation aux résultats hasardeux.

---

Hélas on a pas toujours le choix sur le CPU : machine embarquée limitée, ou (hélas) administration qui refuse l'upgrade de façon automatique.

Citation:

---

Envoyé par Rei Ichido

Ca laisse 10%, ce qui est pas négligeable !

---

Maintenant reste à prouve que c'est du directement au temps d'appel de méthode. N'oublie pas qu'au passage j'ai explosé un algorithme qui, typiquement, est entièrement développé en deux boucles imbriquées :) De plus c'est 10% par rapport à un calcul extrèmement basique qui peu tenir entièrement dans les registre. En pratique les algo explosés en plusieurs méthodes sont loind d'être aussi simple. Et pour infos, le compilateur fait aussi de l'ininling si les méthodes sont prévisibles (appel de méthodes privées, final ou statiques)

Il faudrait quelque chose de plus rigoureux comme test pour éliminer les optimisations qu'aurait pu faire le compilateur en raison de la simplicité du calcul de départ ;) Après tout un très très bon compilateur aurait déroulé mes boucle et précalculer sont résultat, puisque tu peux démontrer qu'il sera toujours le même :mouarf:

Oui oui je connais les méthodes d'inlining, et comme on trouve pas mal de conseil à ce sujet, je me disais que c'était justement pour une bonne raison. Maintenant, j'ai conscience que la plupart des docs sont plutôt datés, d'où je déduis que les gains de l'époque sont franchement compensés par le jit.

Tu peux aussi faire attention aux connexions/déconnexions lors de l'accès aux bases SQL. Il est important de savoir quand on se connecte et quand on se déconnecte. Peut-être que le portage de l'appli a introduit des pbs de ce type :

Code:

---

1 2 3 4 5 6

for () { connect() fonction disconnect() }

---

:scarymov:

coute bcp plus cher que:

Code:

---

1 2 3 4 5 6

connect() for() { fonction() } disconnect()

---

:ccool:

Bien vu sinsin. D'ailleurs, c'est la même chose pour l'écriture d'un fichier :

Code:

---

1 2 3 4 5

for () { open(); write(); close(); }

---

est mille fois plus lent que

Code:

---

1 2 3 4 5

open(); for () { write(); } close();

---

En tout cas, merci pour vos nombreuses lumières ... après quelques heures passées sur le code, effectivement la lenteur vient de requêtes SQL trop nombreuses, pas performantes, et mal placées ... bref, repenser mon sgbd je dois !
saint cloud et @+