Discussion :

[LLB]

Bonjour,

Je cherche à faire un traitement ligne par ligne sur un flux d'entrée. Ce flux est potentiellement très long et je cherche à avoir du code très performant. Pour l'exemple, supposons que je veuille lire/écrire sur l'entrée/sortie standard.

J'ai donc écrit une boucle du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
while (s = System.Console.ReadLine()) != null do
    // traitement
    System.Console.WriteLine(s)

Cependant, cela se révèle être assez lent. Avec un traitement vide, cela m'a pris 12 secondes, alors que d'autres outils (par exemple sed) sont capables de traiter une telle entrée en 2,2 secondes.

J'ai mesuré les performances séparément : la boucle ReadLine prend 2,5 secondes et WriteLine prend 7,9 secondes. J'ai donc essayé d'utiliser un buffer (StringBuilder, en prenant soin qu'il n'y ait jamais de réallocation) pour limiter le nombre d'appels systèmes en sortie. Cela a divisé le temps d'écriture par deux, mais j'aimerais faire mieux.

Comment obtenir des performances comparables à ce que font les programme C, au niveau des entrées/sorties ? Y a-t-il des méthodes plus efficaces que ReadLine/WriteLine pour récupérer des chaines ligne par ligne ?

Merci par avance.

[neptune]

Si tu cherches une grosse performance pour un traitement bien particulier, et que tu possèdes les compétences pour l'écriture en C, voir en Assembleur, tu auras toujours de meilleures performances qu'en .NET.

[LLB]

J'imaginais que les entrées/sorties pouvaient être aussi rapides en .Net qu'en C. Je ne vois pas très bien comment il pourrait y avoir de grandes différences (ok, il y a la gestion des strings, mais c'est censé être négligeable).

Le reste de mon code est de l'assembleur IL généré intelligemment et devrait être particulièrement rapide. De plus, mon code utilise des expressions rationnelles compilées, qui offrent de très bonnes performances (meilleures que celles des programmes C testés).

Et l'avantage principal par rapport au C ? Mon code est juste 10 fois plus court et plus sûr qu'il ne l'aurait été en C. De plus, le binaire est portable.

[anthyme]

je c qu'en java le package java.IO est entièrement managé et super lent comparé au natif d'où l'introduction du package java.nio (new io) bien plus rapide mais non managé.

Qu'en est il des IO .net ?

[neptune]

La perte de performance est liée au côté managé de .NET; j'en suis certain. Il faut voir le contexte d'application. Si ton application doit avoir des très bonnes performances, quelques routines bas niveaux seront l'idéal.

[LLB]

Merci pour la piste, je vais essayer de voir ça.

[LLB]

Après quelques tests, il s'avère que le StringBuilder convient. Je l'initialise avec une capacité assez grande, je fais des append dedans quand je dois écrire et je vide le buffer quand il est rempli.

En comptant le traitement dans la boucle, mon programme est maintenant plus rapide que les programmes C que j'avais en référence. L'IO brute reste plus lente, mais c'est négligeable quand les traitements augmentent.

Bref, résolu !