Forum Programmation.java Lenteur de Java ?

Posté par MiniMoi le 05 janvier 2007 à 13:33.

Étiquettes : aucune

jan.

2007

Bonjour !
Non ce sujet n'est pas un n-ième appel à troll...
En fait depuis quelques temps j'entends pas mal que les machines virtuelles sont le futur de la programmation et quelques benchmarks m'ont convaincu. En gros de ce que j'ai vu, le Java n'est pas tellement moins rapide que le C une fois que la JVM a correctement optimisé la méthode, de l'ordre de 10-20% seulement.

Cependant, je constate que tous les programmes Java que j'utilise sont assez lourds et lents. Je pense en particulier à Azureus, Eclipse, ou même par Looking Glass que j'ai testé il y a peu.

Alors, pourquoi ? Ces programmes sont-ils tous programmés avec les pieds ? Qu'est ce qui rend Java lourd alors que les benchmarks montrent une image assez flatteuse du langage.

Voilà, j'aimerais connaître votre avis, parce que je suis en train de découvrir le Java et c'est tout de même bien mieux conçu que le C++...

# Commencer par le commencement

Posté par Calvin0c7 le 05 janvier 2007 à 13:50. Évalué à 2.

Sur quelle machine utilise tu Eclipse ?
Sur un PC de 2003 (P4 3.2, 1Go de RAM) sous mdv 2007 Eclipse et hyper super réactif (même avec Netbean lancé à côté + hsqldb).

De mon point de vu, les programmes Java que j'ai testé ne justement pas lourd et lent...
- [^] # Re: Commencer par le commencement
  
  Posté par MiniMoi le 05 janvier 2007 à 14:17. Évalué à 2.
  
  Sur une machine assez similaire (PM 2GHz, 1Go), mais même là je le trouve trop lent.
  Enfin je ne sais pas, il manque une certaine impression de fluidité, après je ne sais pas à quoi c'est du. Et puis je ne suis pas le seul à trouver Eclipse trop lent...
  
  Mais la question c'est plutôt : pourquoi il n'y a pas de programmes rapides en Java ? (à ma connaissance)
- [^] # Re: Commencer par le commencement
  
  Posté par ndesmoul le 05 janvier 2007 à 14:28. Évalué à 3.
  
  Le gros problème de Java c'est qu'il bouffe pas mal de mémoire vive... Si tu est un peu juste ça peut ramer effectivement.
  
  Le ressenti lourdeur peut venir aussi de l'interface graphique. Azureus et Eclipse utilise SWT et sont plutôt moins réactifs (en tout cas Eclipse) sous Linux que sous Windows, encore que la différence tend à diminuer mais c'est très subjectif.
  D'ailleurs curieusement les dernières versions de Netbeans semblent plutôt plus réactives qu'Eclipse.
  
  Sinon il sera sans doute possible de faire des choses intéressantes avec QT:
  http://www.trolltech.com/developer/downloads/qt/qtjambi-tech(...)
  - [^] # Re: Commencer par le commencement
    
    Posté par MiniMoi le 05 janvier 2007 à 14:50. Évalué à 2.
    
    D'accord, merci pour ces précisions, le problème de Java serait donc lié à l'interface graphique... C'est dommage, mais effectivement les bindings de Qt devraient pas mal aider...
    
    Pour la mémoire je savais déjà, c'est lié au Garbage Collector et à des optimisations de la JVM.
    
    Je vais essayer de me faire mon avis, mais peut-être que je vais abandonner le C++ maintenant...
    - [^] # Re: Commencer par le commencement
      
      Posté par ndesmoul le 05 janvier 2007 à 15:06. Évalué à 2.
      
      Bah disons que la vitesse de SWT est (était?) meilleure sous Windows que sous Linux. Pour ce qui est de Swing (le toolkit graphique standard de Java) les perfs ont été pas mal améliorées dernièrement.
      
      Je suis pas certain que cela soit lié au Garbage collector sauf ponctuellement. Par contre les optimisation de la JVM peuvent jouer au début. Par exemple la première fois que tu cliques sur un menu il met une seconde à s'afficher alors que c'est instantané ensuite.
      
      Pour faire rapidement une GUI en Swing, jette un coup d'oeil du côté de Netbean qui propose maintenant une système de création d'interface qui semble assez bien foutu (mais je ne l'ai pas testé de manière appronfondie).
# Java oui, c'est lent

Posté par Pascal le 05 janvier 2007 à 15:38. Évalué à 4.

Java, oui c'est lent, c'est comme ca.... JAVA utilise une machine virtuelle, et en théorie, on a:

Langages de scripts (bash,....)
sont plus lents que
Langages à VM (JAVA, Python, Perl, ....)
sont plus lents que
Langages C/C++
sont plus lents que
Assembleur

Mais tout cela,n'est que de la théorie. La vitesse d'un programme dépend aussi ttès fortement de la manière dont il est codé. Un programme JAVA bien programmé sera certainement plus rapide que son équivalent en C programmé avec les pieds.

Je pense aussi qu'un autre facteur est que dans le culture JAVA, on ne pense pas vraiment aux performances, mais plutot à la lisibilité/simplicité/fiabilité du code. Alors que tous les programmeurs assembleurs ont une culture de la performance/optimisation.

Par exemple: Combien de programmeurs JAVA pensent à faire un décallage pour réaliser une multiplication/divison par 2,4,8 ?
Combien de programmeurs JAVA jouent avec les concaténation de String tout va sans comprendre ce que cela implique au niveau performances ?
- [^] # Re: Java oui, c'est lent
  
  Posté par Calvin0c7 le 05 janvier 2007 à 15:46. Évalué à 2.
  
  Combien de programmeurs JAVA pensent à faire un décallage pour réaliser une multiplication/divison par 2,4,8 ?
  
  Ca je sais : 0
  
  Combien de programmeurs JAVA jouent avec les concaténation de String tout va sans comprendre ce que cela implique au niveau performances ?
  
  Là je serai plus circonspect, StringBuffer est quand même bien connu et largement utilisé. Le moindre cours Java de base précise (en même temps que la différence entre = et equals()) que les String sont des objects non modifiable.
  - [^] # Re: Java oui, c'est lent
    
    Posté par ndesmoul le 05 janvier 2007 à 15:52. Évalué à 2.
    
    Si tu n'as pas de risque que ton Stringbuffer soit modifié de manière concurrente par deux threads, mieux vaut utiliser un StringBuilder qui est la même chose qu'un StringBuffer mais en non synchronisé et donc un peu plus rapide.
  - [^] # Re: Java oui, c'est lent
    
    Posté par Alex le 05 janvier 2007 à 17:28. Évalué à 2.
    
    Combien de programmeurs JAVA pensent à faire un décallage pour réaliser une multiplication/divison par 2,4,8 ?
    
    Ca je sais : 0
    
    Et est-ce vraiment un mal ?
    - [^] # Re: Java oui, c'est lent
      
      Posté par Pascal le 05 janvier 2007 à 18:03. Évalué à 2.
      
      Et est-ce vraiment un mal ?
      
      Non pas du tout, la seule chose que je voulais démontrer est que les programmeurs Java sont rarement intéréssés par les performances et l'optimisation de leurs programmes
      - [^] # Re: Java oui, c'est lent
        
        Posté par TImaniac (site web personnel) le 05 janvier 2007 à 20:51. Évalué à 6.
        
        Ca veut rien dire du tout. Le vrai programmeur moderne, il sait pertinamment que ce genre d'optimisation est laissé à la discretion du compilateur; à part rendre le code illisible, le décalage de bit pour effectuer une division par une puissance de 2 n'a plus grand intérêt de nos jours.
        Le programmeur ferait mieux de penser à optimiser son algo plutôt que de faire son malin avec des décalages de bits.
  - [^] # Re: Java oui, c'est lent
    
    Posté par Pascal le 05 janvier 2007 à 18:15. Évalué à 3.
    StringBuffer est quand même bien connu et largement utilisé
    Oui mais beaucoup de programmeurs continuent à faire des choses comme ça:
```
public String concateneStrTab(String tab[])
{
     int i;
     String str = "";
     for(i=0;i<tab.length;i++)
          str += tab[i];
     return str;
}
```
    Et le langage t'y pousse. En effet, cette solution est au premier abord largement plus simple et naurelle que d'utiliser des StringBuffer. Alors que le langage C par exemple, te pousseras à trouver une solution bien plus optimale.
- [^] # Re: Java oui, c'est lent
  
  Posté par ndesmoul le 05 janvier 2007 à 15:46. Évalué à 2.
  
  Oui je suis assez d'accord. Sauf que Java c'est tout de même plus rapide que Perl ou Python qui sont purement interprétés.
  - [^] # Re: Java oui, c'est lent
    
    Posté par Alex le 05 janvier 2007 à 17:33. Évalué à 2.
    
    Faudrait demander à des experts de ces 2 langages, mais ils me semble que python est compilable, et que perl "precompile" dans une forme de bytecode, le toute pour accelerer les perfs bien sur (les mauvaises langues diront que cest pour rendre le code plus lisible ;) )
    Ruby lui est purement interprété (en attendant ruby 2)
    
    Il y a un moment j avais vu des benchs de différents langages, et j avais été impréssioné par les regexp de perl, qui s en sortait dans les premières places.
    
    En dehors de ça, est-ce que les perfs sont vraiment le point clef pour le choix d un langage ?
    ca depend du contexte me direz vous
  - [^] # Re: Java oui, c'est lent
    
    Posté par Pascal le 05 janvier 2007 à 18:18. Évalué à 2.
    
    Perl et Python ne sont pas interprétés, mais comme JAVA, ils utilisent une machine virtuelle.
    
    Ils donnent l'impression d'être interprétés car en fait, la compilation est réalisée juste avant l'éxecution.
    
    Après je ne saurais pas te dire s'ils sont plus ou moins performants que JAVA.
    - [^] # Re: Java oui, c'est lent
      
      Posté par パパフラクス le 08 janvier 2007 à 12:09. Évalué à 2.
      
      Python est sensiblement plus lent que Java.
      Mais Python favorise l'utilisation de lib natives,
      par exemple pour le calcul numérique, ce qui équilibre les choses.
      
      Cependant de mon expérience cette lenteur relative ne devient que rarement pénalisante.
      
      Pour moi, sur un algo d'apprentissage numérique, la phase d'apprentissage était vraiment super lente. Mais je l'avait un peu fait exprès, j'avoue, en implémentant naïvement l'algo entièrement en Python, pour voir le gain et la facilité d'utiliser Numeric plus tard.
      
      La "migration" vers Numeric a été super rapide, et le gain plutôt impressionnant.
      
      Il existe également <a ref='"http://psyco.sourceforge.net/introduction.html">Psyco qui permet d'améliorer les perf.
      Cependant je n'ai jamais essayé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.