Sortie de Xemeiah 0.4.12 : encore un processeur XSLT

Posté par . Modéré par patrick_g.
Tags :
9
9
juin
2009
Ligne de commande
Xemeiah est une bibliothèque XML écrite en C++, orientée performance et évolutivité. Sous licence GNU GPL, Xemeiah est construit autour d'un DOM (Document Object Model) optimisé pour la prise en compte de larges contenus XML, et d'un processeur XML dynamique prenant en charge les langages XSLT et XUpdate.

La version 0.4.12 contient un processeur XSLT complet (passant 94% des tests Oasis de conformité à la norme XSLT).

Très performant en termes de temps d'exécution, Xemeiah rivalise largement avec les autres alternatives libres (Xalan, XSLTProc), et reste bien plus efficace que les implémentations Java.

NdM : XSLT, eXtensible Stylesheet Language Transformations, est un langage de transformation XML de type fonctionnel. Il est utilisé par exemple pour transformer des documents XML en page HTML ou XHTML. XUpdate est un langage léger permettant d'interroger et modifier un document XML.
  • # ...

    Posté par . Évalué à 10.

    écrite en C++et reste bien plus efficace que les implémentations Java

    Heureusement !
    :)
    • [^] # Re: ...

      Posté par (page perso) . É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 . Évalué à 5.

        faut voir les consos de RAM, aussi...
        • [^] # Re: ...

          Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à -1.

              Aïe ! pas la tête ! pas la tête !
            • [^] # Re: ...

              Posté par . Évalué à 2.

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

                Posté par . É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 . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.