Sortie de Xemeiah 0.4.12 : encore un processeur XSLT

• # ...

  Posté par fcartegnie le 09 juin 2009 à 13:27. Évalué à 10.

  

  écrite en C++et reste bien plus efficace que les implémentations Java
  
  Heureusement !
  :)

  • [^] # Re: ...

    Posté par Benoît Bâlon (site web personnel) le 09 juin 2009 à 15:57. Évalué à 0.

    

    C'est un troll, ça ? Les implémentations Java sont-elles *carrément* inefficaces car incapables de faire correctement le boulot, ou bien sont-elles *seulement* moins performantes en terme de rapidité ?

    • [^] # Re: ...

      Posté par Gniarf le 09 juin 2009 à 16:28. Évalué à 5.

      

      faut voir les consos de RAM, aussi...

      • [^] # Re: ...

        Posté par Benoît Bâlon (site web personnel) le 09 juin 2009 à 16:39. Évalué à 4.

        

        Oui, certes, mais il y a des domaines où le Java est privilégié, ainsi que d'autres langages de programmation, et pas du tout le C++. Je veux parler du Web, bien entendu, où les langages plus lents et plus gourmands sont légion...
        
        Personnellement, au risque de me faire arracher la tête par certains, je ne trouve pas Java plus lourd que Python. Mais une chose est sûre, la plupart des langages modernes répondent à des besoins souvent très différents (temps réel dur = C par exemple), et parfois même des domaines de niche. Du moment que ce langage remplit parfaitement les besoins pour lesquels on l'utilise (développement, maintenabilité, performances...), j'imagine qu'il est tout à fait efficace. Après, qu'il soit trop lent ou trop gourmand, c'est une question de développement et de domaine d'application.

        • [^] # Re: ...

          Posté par Julien le 09 juin 2009 à 20:50. Évalué à 1.

          

          "Personnellement, au risque de me faire arracher la tête par certains, je ne trouve pas Java plus lourd que Python"
          
          -> tu plaisantes j'espère .. ?
          
          OK Java est quasi aussi rapide que du C/C++, OK Java a de très bonnes specs (cf JDBC, etc) ... mais franchement au niveau de la consommation mémoire c'est parfois n'importe quoi (parfois je me demande même s'il y a un GC..). Par exemple la j'ai un Tomcat avec _une_ appli qui utilise Spring, Hibernate, Lucene ... paf 600 mo de RAM. Geoserver avec Jetty ? -> des pointes à 800 mo de RAM.
          
          J'ai tendance à trouver que tout en Java est lourd et uber compliqué. Prends les EJB, Hibernate vs SQLAlchemy en Python, Spring vs Pylons, etc

          • [^] # Re: ...

            Posté par Benoît Bâlon (site web personnel) le 09 juin 2009 à 21:42. Évalué à -1.

            

            Aïe ! pas la tête ! pas la tête !

          • [^] # Re: ...

            Posté par lasher le 10 juin 2009 à 01:32. Évalué à 2.

            

            OK. Si on parlait multithreading sur systèmes multi-cœurs/multi-processeurs ? Ah ben zut, python fait pas. :-/

            • [^] # Re: ...

              Posté par Larry Cow le 10 juin 2009 à 11:16. Évalué à 2.

              

              Multi-threading, non. Parallélisme, oui, notamment grâce au module (multiprocessing, c'est ça?) intégré dans Python 2.6.

              • [^] # Re: ...

                Posté par lasher le 11 juin 2009 à 10:06. Évalué à 2.

                

                Sauf que faire du multi-processus ça veut dire installer tout un tas de mécanismes pour pouvoir passer les données à son processus voisin, alors qu'avec le multithreading les données sont partagées. Et surtout, la consommation mémoire est moindre pour une application multi-threadée comparée à son équivalent multi-processus.

          • [^] # Re: ...

            Posté par collinm (site web personnel) le 10 juin 2009 à 02:39. Évalué à 1.

            

            tu as une panoplie de framework libre a toi de les utiliser ou non
            
            tu peux tout à faire ne pas les utiliser et gérer x fonctionalité toi même.... mais ainsi tu augmentes ton travail
            
            ensuite bon si tu utilises 18 frameworks dans ton application.... c'est qu'il y a un problème de gestion... le gestionnaire fait n'importe quoi...
            
            faut penser à ce qu'on veut faire... et choisir en fonction de ça... et non regarder ce qui est à la mode et l'utiliser...

            www.solutions-norenda.com

    • [^] # Re: ...

      Posté par Yannick le 09 juin 2009 à 17:00. Évalué à 3.

      

      Un vrai de vrai ...
      
      http://wiki.java.net/bin/view/Games/JeffOnPerformance
      
      Article datant de 2005 ... mais les vrais trolls sont ceux qui durent ...
      
      Cela dis ça ne m'étonne pas, j'ai déjà passé beaucoup de temps dans mon entreprise pour convaincre les vieux programmeurs accro au C (puis contraint a faire du C++) que tout ces langages se valent.
      
      Bien entendu je parle ici dans le cadre d'application d'ordre professionnel, traitant de gros volumes de données, du multi-threading, une part de base de données, des algorithmes mathématiques, ...
      
      Dans ce contexte la, java peut être fier de ses performances.
      
      Après qu'une applet soit lente a démarrer ou moche à regarder je conçoit que ça gène Madame Michou, et que du coup ça lui donne l'impression que java soit moins performant (le troll se nichant ici).

      • [^] # Re: ...

        Posté par lasher le 09 juin 2009 à 17:54. Évalué à 3.

        

        Hem. Je suis plutôt d'accord avec toi sur le fait que Java n'est pas si mauvais en termes de perfs, mais il y a quelques limites quand mêmes ... Parce que bon, tes histoires d'algos d'analyse numérique, s'il s'agit d'algèbre linéaire dense par exemple, sauf à avoir des classes qui en réalité passent par du C en sous-main, malheureusement Java est derrière le langage C. Il y a d'autres domaines où au contraire Java rivalise sans rougir avec C++ bien sûr.
        
        Mais quand même globalement, en termes de consommation mémoire et de rapidité, quand la latence réseau n'est pas le facteur limitant, Java reste globalement moins rapide que C (après parfois il s'agit d'un « à peine moins rapide » et du coup, autant se simplifier la vie et rester sur Java, bien sûr).

        • [^] # Re: ...

          Posté par yellowiscool le 09 juin 2009 à 18:10. Évalué à 3.

          

          Moi ce que j'aime le plus en java, c'est le garbage collector imposé: «les delete, c'est trop pénible pour gérer les memorys leaks, supprimons les deletes!».

          Envoyé depuis mon lapin.

          • [^] # Re: ...

            Posté par lasher le 09 juin 2009 à 18:16. Évalué à 1.

            

            Ben je suis assez d'accord en fait. Une des premières sources de bugs dans les programmes c'est quand même les problèmes de gestion mémoire. D'ailleurs ce n'est pas pour rien que Boost en C++ permet d'avoir des pointeurs « magiques » (avec comptage de références). Alors certes, ça implique une certaine perte de perfs, mais qu'est-ce qu'on y gagne en temps de débogage !

• # .

  Posté par Sylvestre Ledru (site web personnel) le 09 juin 2009 à 17:10. Évalué à 1.

  

  En effet, Saxon est pas modèle de rapidité sur des gros fichiers :/
  
  Ceci dit, j'ai voulu essayé xemeiah mais il arrive pas à importer les styles de docbook-xsl (html.xsl ou javahelp.xsl). Pas encore assez évolué ?
  
  Rien à voir mais le package Debian gagnerait à contenir un peu de documentation...

  • [^] # Re: .

    Posté par forgoto le 09 juin 2009 à 19:20. Évalué à 1.

    

    Oui, il y a encore pas mal d'épreuves du feu à passer...
    Notamment le parsing des entités, qui ne devrait pas tarder à arriver (prévue en 0.4.14).
    Une manpage existe également, le tout dans les prochains jours.

  • [^] # Re: .

    Posté par forgoto le 11 juin 2009 à 05:01. Évalué à 1.

    

    Ayé, la release 0.4.14 est dans les bacs, et donne de bons résultats pour les sorties manpage et html... [[http://sf.net/projects/xemeiah]]
    
    Donc si tu as l'occasion de re-tester, ton retour m'intéresse !

• # Comparaison avec AntennaHouse

  Posté par elloco (site web personnel) le 09 juin 2009 à 19:50. Évalué à 1.

  

  Salut,
  Est-ce que ce processeur XSLT est aussi rapide / plus rapide que le processeur "Antenna House" (logiciel propriétaire mais tellement efficace) ?
  Merci

  • [^] # Re: Comparaison avec AntennaHouse

    Posté par Mallow Hober le 10 juin 2009 à 09:27. Évalué à 1.

    

    Salut,
    Il me semble qu'Antenna ne traite que les XSL-FO, la partie XSLT est gerée par default avec msxml et tu peux même l'utiliser avec saxon.

Suivre le flux des commentaires

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