bug dans titre

• [+] [^]vaut mieux qu'il y en ait dans le titre...

  Posté par sToR_K () le 28/01/2002 à 21:31. (lien). Évalué à -1.

  ...que dans le kit :)
  
  
  
  "rapidité de SWING (GUI)"
  
  ->lol
  
  
  
  -1; tapez-pas; [jesors];

  • [^]Re: vaut mieux qu'il y en ait dans le titre...

    Posté par Axel R. (page perso, ) le 28/01/2002 à 23:14. (lien). Évalué à 12.

    bah, justement... des améliorations ont été faite...
    
    C'est ça l'avantage de partir d'aussi bas, c'est qu'on ne peut qu'évoluer...
    
    J'en profite pour parler d'un article dans le dernier linux Magazine sur les desktops/window manager/serveur X entierement en java...
    
    J'ai pas tout compris, je sais pas trop ce qu'à pris le pigiste qui a pondu l'article, mais ça avait l'air d'être de la bonne :-)
    
    L'idée de ne pas avoir de JVM a lancer à chaque lancement d'appli, c'est super comme idée (c'est aussi pour ça que je suis pour le java coté serveur... on redemarre pas les serveurs tous les jours...)
    
    Si y'a des p'tits gars qui y ont gouté (aux clients 100% java) ça serait sympa d'avoir des retours d'expérience :-)
    
    
    
    Axel - 584

    • [^]Re: vaut mieux qu'il y en ait dans le titre...

      Posté par vrm (page perso, ) le 29/01/2002 à 08:28. (lien). Évalué à 6.

      Je code des clients java,
      
      Swing c'est lent, ca mange enormement de memoire mais c'est tellement bon ;)
      
      
      
      Je prefere avoir un truc qui ramme un peu, qu'une appli Inmaintenable codé à l'arrache en C++ Builder ..

      • [^]Re: vaut mieux qu'il y en ait dans le titre...

        Posté par reno () le 29/01/2002 à 10:01. (lien). Évalué à 4.

        Je confirme, j'aime bien le design de Swing beaucoup moins les bugs, la lenteur et la consommation memoire..
        
        
        
        Puisque tu codes actuellement, tu as vu une difference avec la version 1.4.0 au niveau vitesse/occupation memoire?
        
        Enfin si tu es passe a la nouvelle version, bien sur.

        • [^]1.4

          Posté par Le Mollusque Courtois () le 29/01/2002 à 23:45. (lien). Évalué à 4.

          J'ai eu des échos très positifs concernant la vitesse avec 1.4.
          
          C'est assez normal, la technique de la JVM est très intéressante maintenant :
          
          1.0/1.1 : c'était uniquement de l'interprété -> lent
          
          1.2/1.3 : compilation Just-in-Time, beaucoup plus rapide mais pas encore ca.
          
          1.4 : non seulement la JVM compile mais elle optimise juste avant l'exécution. Elle est capable de rendre inline les fonctions, et ce basé sur l'analyse qu'elle fait du code. Avec une JVM vraiment intelligente, ça permet de faire du code optimisé en dynamique, et non une fois pour toutes à la compilation. C'est potentiellement plus rapide que du C compilé. Evidemment faut voir ce qu'il en est avec cette JVM là, mais apparamment c'est déja honnete.

          • [^]Re: 1.4

            Posté par Pierre Tramo (page perso, ) le 30/01/2002 à 02:51. (lien). Évalué à 2.

            Elle est capable de rendre inline les fonctions
            
            
            
            en cours, on nous a présenté des benchs de SmallEiffel avec la fonction inline désactivée puis activée. y'a pas à dire le gain de perf est énorme, alors si en java on le fait aussi, çà va être de la bombe (effectivement, encore faut-il bien le faire)
            
            
            
            ps : pour ceux qui ont du mal à suivre : la fonction inline consiste à remplacer un appel de méthode par le corps de la méthode (équiv d'une macro en C) -> très utile pour les méthodes du genre :
            
            int max(int i, int j) { return i>j ? i : j; }

            • [^]Re: Complement d'infos...

              Posté par thibs (page perso, ) le 30/01/2002 à 06:02. (lien). Évalué à 2.

              Attention cependant (en C++ notamment) a ne pas tomber dans l'exces qui consiste a mettre du inline partout !
              
              En effet, l'inline brise le principe d'encapsulation (un concept important de l'approche objet) qui veut que le code des methodes soit cach'e a l'utilisateur. De plus, il faut savoir utiliser le inline a bon escient. Si la methode fait une ligne de code, ca passe. Si elle en fait 20, la passer inline va rendre difficile la lecture du fichier d'entete !
              
              Avant de se dire "ouais, je vais foutre du inline partout, ca va etre putain d'optimis'e", il est bon de deceler les goulots d'etranglement de l'application afin de cibler l'optimisation. En effet, il ne sert a rien de gagner qques 10emes de sec sur une partie du code quand une autre prend 2 secondes a s'executer !
              
              Enfin, il faut savoir que dans la mesure du possible, le compilateur se charge de passer des methodes inlines lorsqu'on l'appelle avec l'option d'optimisation.
              
              Voila.. rien que l'info mais toute (?) l'info ;)

    [^]Swing-in'

    Posté par Jean-Christophe ARNU (page perso, ) le 29/01/2002 à 09:27. (lien). Évalué à 5.

    OK swing n'est pas rapide à la base mais là ils ont fait un réel effort sur la présentation :)
    
    
    
    Nos applis s'en ressentent et deviennent beaucoup plus snappy!

  [^]bug dans LE titre

  Posté par nico () le 29/01/2002 à 08:28. (lien). Évalué à 1.

  En France, on parle de chiffrement...
  
  
  
  Nico - mes 30 cts