Lexpage, heuuuuu c'est bien hein ??    —  Pecnol

Discussions

Go - Enregistrement d'une date d'un xml dans ES

Fabe 607 Geek
Reprise automatique du message précédent.
Si à l'occasion tu tombes sur des benchmark qui te semblent comparables, ça m'intéresse. C'est pas évident de rester à jour sur l'évolution de chaque techno et leur positionnement relatif.
Guybrush 8343 Bob
Je t'avoue que je clique rarement sur les liens menant à des benchmarks parce qu'ils sont souvent bien trop "spécifiquement choisis" pour être représentatifs (je ne compte pas le nombre de benchmarks faits par la communauté Python pour tenter de faire croire que Python n'est pas une catastrophe niveau perfs :-D).

En général, je m'intéresse plutôt aux benchmarks pour comparer des solutions à un même problème (typiquement dans un contexte d'analyses de données, où tu peux soit partir sur Pandas/numpy et profiter de perfs en C, soit via Cython pour ajouter quelques annotations de types C et compiler le code Python directement en C à la volée, soit numba qui fait du JIT à la volée, ou encore pypy quand c'est un code one-shot et que je veux pas me prendre la tête et juste avoir une solution drop-in).

Python est clairement en dessous de la majorité des langages modernes coté performances. C'est un argument que l'on rencontre souvent à l'encontre du langage, mais qui finalement ne m'a jamais vraiment posé problème, même quand le temps de calcul pouvait être long. Souvent, il suffit de "mieux réfléchir" et on peut gagner un joli facteur 2 ou 3 (et une qualité de code supérieure), et il existe de nombreuses possibilités pour optimiser le code si vraiment c'est nécessaire, allant des choses "simples à déployer" à des choses "moins simples à déployer" (je vais me répéter un peu du coup) :
- Utiliser PyPy au lieu de CPython : l'interpréteur par défaut peut facilement être remplacé par PyPy pour (espérer) gagner un peu de perfs. Ca marche dans les cas classiques ou l'essentiel du code est du Python et pas des extensions C. Merci JIT !
- Utiliser la bonne librairie : numpy au lieu des builtins de Python et on a un miracle en terme de perfs. Malheureusement pour moi, j'utilise déjà numpy de façon systématique dans mes projets, donc je ne gagne pas grand chose de ce coté là.
- Cython: Il "compile" le code Python en C, ce qui permet de gagner un facteur 2 à 3 gratuitement, et la compatibilité est totale. C'est une bonne idée pour un batch, mais difficile à exploiter correctement dans un notebook interactif du coup (même si c'est possible et pas mal géré). On peut aussi ajouter des annotations de type (cdef int, cdef char, etc.) pour indiquer quelles variables Python doivent être "encodées" dans quelles variables C (au lieu de passer par une struct object habituelle). Le gain est parfois impressionnant (et on peut faire ces annotations dans un fichier "à part", donc le code reste aussi exécutable en pur python). Ca peut monter jusque 200x à 300x dépendant des cas et des bottlenecks.
- Numba: Un projet assez récent, qui consiste à simplement ajouter un "@numba" (le décorateur Python) aux fonctions à "optimiser". L'idée est qu'il va automatiquement déduire les types utilisés lors d'un appel. Si la fonction est sans effet de bords, et bien codée (comprendre : elle ne fait pas le café et se focalise sur quelques routines/calculs), le gain est aussi de l'ordre de 200 à 300x. Malheureusement, numba est très très capricieux, et certains cas ne sont pas optimisés et ralentissent même l'exécution du code (le projet est encore jeune).
- Extension C : le plus classique, car Python a un très très bon support pour ça : on écrit le code d'une routine en C, et on peut directement l'importer et l'utiliser depuis Python. Evidemment, il faut descendre dans un langage bas niveau mais ça fait des miracles, puisqu'on a exactement les perfs de C pour l'exécuter, et que vu que l'usage du code C est pratiquement transparent en Python, on peut simplement considérer la lib "externe" comme étant du plain Python sans se soucier des conséquences.
yaug 1450 Spammeur
Hello, j'ai besoin d'un nouveau coup de main.

J'essaye de décoder ce XML :
<Article PubModel="Electronic">
<Journal>
<ISSN IssnType="Electronic">2041-1723</ISSN>
<JournalIssue CitedMedium="Internet"></JournalIssue>
<Title>Nature communications</Title>
<ISOAbbreviation>Nat Commun</ISOAbbreviation>
</Journal>
<ArticleTitle>Contractile forces at tricellular contacts modulate epithelial organization and monolayer integrity./ArticleTitle>
</Article>
Pour ce faire j'utilise la lib encoding/xml et sa fonction unmarshal.
Les structs pour le mapping :
type Journal struct {
Title string `json:"Title"`
}
type Article struct {
Journal Journal `json:"Journal"`
Title string `json:"ArticleTitle"`
}
Problème, si j'arrive à unmarshal le Journal et son Titre, impossible de faire de même pour le titre de l'Article.
ça ne serait pas du à la majuscule au milieu du champ xml qui poserait un problème à la Réflexion ?
Qu'en penses tu @Fabe ?
Fabe 607 Geek
yaugQu'en penses tu @Fabe ?
2 trucs 🙂

Ton xml est invalide:
<ArticleTitle>Contractile forces at tricellular contacts modulate epithelial organization and monolayer integrity./ArticleTitle>
Vu que tu arrives quand même à Unmarshal je suppose que ce n'est pas le cas chez toi, mais c'est peut-être signe que tu ne traites pas l'error en retour de Unmarshal 😉

Sinon la vraie cause est que tu as utilisé le tag json pour indiquer le mapping, alors que encoding/xml ne lit que le tag xml. Cf doc d'Unmarshal:
Unmarshal maps an XML element to a struct using the following rules. In the rules, the tag of a field refers to the value associated with the key 'xml' in the struct field's tag (see the example above).
En modifiant les structs ça fonctionne: play.golang.org/p/FKEMnn…
type Journal struct {
Title string `xml:"Title"`
}

type Article struct {
Journal Journal `xml:"Journal"`
Title string `xml:"ArticleTitle"`
}
{{Nature communications} Contractile forces at tricellular contacts modulate epithelial organization and monolayer integrity.}
Auparavant ça fonctionnait par convention: les Fields ayant le même nom que les tags XML étaient correctement mappés.


Ce message a été modifié 5 fois. Dernière modification : 26 juillet 2018 à 10:33 par Fabe.

yaug 1450 Spammeur
Tu la sens la fatigue ? :D

Merci d'avoir vu cette aberration que j'avais sous le nez depuis des heures...
Cela me débloque à merveille du coup.
Merci

Répondre

Vous devez être inscrit et identifié.