pognibene2 a écrit 2 commentaires

  • [^] # Re: De tout temps ...

    Posté par  . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 3.

    En optimisant correctement ton C++ tu peux avoir des gains allant jusqu'à 200% voire plus (dès que l'on touche à des fonctions natives du système). Pour 20 ou 30% çe ne serait pas très intéressant :-)

    Quand à la maintenabilité et évolutivité du code, si ton C++ est correctement écrit ça ne pose pas de problèmes. (Evidemment c'est
    le 'si' qui pose problème, C++ étant très permissif).

    Je suis d'accord, ça dépend des projets. Par exemple, pour du serveur d'application, Java est à sa place (ou dans des applets).

    Par contre, développer un soft de traitement d'image en Java...
  • [^] # Re: De tout temps ...

    Posté par  . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 8.

    Désolé, c'est mon premier post et je ne trouve pas comment recopier le texte original (marche pas sous Mozilla)

    A propos de la rapidité de Java : le dernier troll sur Slashdot n'apporte rien de neuf. A l'heure actuelle des tests *fonctionnels* écrits en Java vont aussi vite que du C++.

    Mais du C++ optimisé (c'est à dire en utilisant par ex l'allocation sur la pile, en évitant les créations inutiles d'objets, etc) reste plus rapide que du Java.
    Tout simplement parce que la librairie de classe de Java créé beaucoup d'objets intermédiaires. C'est propre mais lent.

    Ceci rend également Java non prédictible. Dans le domaine des telco où je travaille, Java n'est pas utilisé pour gérer des serveurs avec des contraintes de temps fortes par exemple. (mais il y a des versions spécifiques des JVM pour le temps réel)

    A propos des threads : Java n'utilise pas massivement les threads. L'architecture J2EE les utilise par contre beaucoup. Le problème des anciens noyaux était:
    1) le coût de création du thread car sous Linux un process et un thread c'était la même chose
    2) le coût de changement de contexte sur des opérations impliquant les mutex

    Ceci n'est un frein que si on crée et détruit de très nombreux threads et si les mutex sont massivement utilisés. Là encore, en Java pur ça n'a aucune importance. En J2EE c'est important, mais uniquement si les clients J2EE sont codés avec les pieds, c'est-à-dire s'ils créent et détruisent de nouveaux EJB
    sans arrêt, au lieu de garder une référence de session bean et ne pas exposer
    l'aspect interne de l'application.

    Pour en revenir à Eclipse, puisque il s 'agit du point de départ, je l'ai essayé...
    Et laissé tomber tout de suite. L'interface est inutilisable de lenteur
    et les fonctionnalités offertes ne m'ont pas convaincu. Je suis plus efficace avec
    emacs ou gvim :-)