Reprise du message précédent :
petite question, j'ai beaucoup de fichiers texte d'output d'une appli de calculs. Genre plus de 50.000 lignes, des fichiers de 3Mo en moyenne (voir beaucoup plus mais c'est rare).
 
pour l'extraction j'ai des scripts shell et du perl mais ca pue un peu comme methode. J'aimerai faire un truc plus gros avec une tite intereface a la con pour choisir les donnees que je veux extraire et generation de fichiers csv en sortie, le tout en recursif sur des repertoires.
 
Si j'ai disons 20 a 50 (ou beaucoup plus) fichiers de cette taille, en java vous pensez que ca risque de prendre du temps sur une machine de base (mon iBook ou ma station linux)? parce que java en terme de parsage de fichier plat, il est reconnu comme etant rapide

suffit de savoir s'y prendre, je vois pas pourquoi ça serait plus lent qu'un autre langage. seulement par defaut, le neuneu de base va pas prendre la bonne méthode.

c'est bien ce que je pensais mais apres en terme de performance, tu vas pas me faire croire que java peut aussi bien faire que Perl quand meme (pour parser j'entend)

et pourquoi pas

parce que
 
(parce que je dois etre un neuneu de base et que le derniere fois que j'ai fais une petite classe pour me le faire,ca rammait et en perl ca roxait )

ha ben j'ai pas dit que JE saurais le faire aussi, mais dans l'absolu y'a pas de raison. maintenant, oui, en perl tu le fais en 4 lignes, en java il t'en faudra bcp plus pour faire un truc aussi performant

de toute facon, ma decision etait prise, ce sera en java parce que j'aime ca.  
mais je demandais pour la forme, et aussi pour avoir des et des

>uriel, j'ai pas l'impression que tu auras l'ombre d'une comparaison entre un traitement java et un traitement shell script.

uriel > t'as raison.
 
si dans tes produits dérivés, tu pouvais avoir un JLex et un Cup "dynamiques", ça m'arrangerait /o\

ca vaut dire quoi ca

pas compris non plus (la partie JLex, c'est bon mais c'est tout)

moi g rien compris à JLex tout court .... (enfin si JLex ca allait, c CUP où g vraiment du mal malgré un prof patient et compréhensif

Uriel, je veux dire que les perf seront très certainement bien en dessous, sauf cas particuliers. Même en étant soigneux en Java, ça risque de pas le faire. D'expérience, j'ai souvent été déçu - et je te parle pas de la fois où le traitement shell comprenait un sort.
 
Et je ne pense pas être un neuneu, ni être un troll du genre "java c'est lent" (si qqn avait eu un seul instant l'idée de faire un tel commentaire)
 
Au mieux, ça demande une qté de code substantiellement plus importante, bien sûr.
 
Maintenant, qqn a peut-être une meilleure expérience ?

l'avantage que j'y voyais c'etait les avantages de java en terme de reutilisation. evidemment on doit pouvoir faire de meme avec le semblant de POO de perl, mais je touche pas assez en perl pour le faire de suite, j'ai egalement pense a python (egalement pour l'interface) mais java me plait

Java n'est pas vraiment adapté à des traitements fichiers, généralement mieux servis par des scraïpts.
 
Maitenant, à toi de voir si le gain en réutilisation (est-il bien concret ?) et ton envie de le faire en java pour le plaisir de le faire en java le justifient.
 
Commence par isoler un bout de traitement et compare les deux techniques (ou trois ou quatre). Je serais pas étonné du tout que java te demande plus de boulot pour des perf moindres.
 
Essaye un tri, juste pour (mourir de) rire.

ouais, je le fais ce pas, un petit benchmark

Bon alors comme ça fait longtemps, j'vais sauter à pieds joints dans le troll
T'as un cas concret sous la main ? Genre sur un même fichier, le même parsing avec la même méthode c'est vachement plus long en Java qu'en Perl et ça demande plus de code ? J'demande à voir passke franchement je suis sceptique
Surtout le deuxième point, en fait, le coup de la quantité d'code
 
'fin bref, j'veux bien qu'on dise que Java soit mal foutu sur tel ou tel point mais sur un truc aussi général que le parsing de fichier, euh...

à propos de l'autoboxing (ma question vaut aussi pour C#) : on ne pourrait pas envisager que le compilateur donne un coup de main ? De sorte qu'invariablement, on déclarerait Integer (ou int au choix), le compilateur manipulant le type primitif nu ou boxé en fonction de son contexte d'utilisation ?  
 
non, en fait je suis stupide, il suffit d'utiliser en permanence avec le type primitif. Quoi qu'en fait, il faudrait que je regarde si y a pas trop de box/unbox intempestif. En ce moment je regarde un peu ce que fais mono. Si je fais

cela me donne 2 fois la même séquence d'instructions, 2 boxing. Je délire complètement mais je me demande si le compilateur doit optimiser le flot d'instruction ou prendre le problème au niveau de la sémantique.
 
 
au fait, en java
 

pourquoi ceci ne marche pas ?
 
 
si je suis HS, il faut me le dire, je dégage direct, désolé

Ca vient d'où, c't'affirmation ?

Ba franchement, vaut mieux coder proprement et avec motivation dans un langage X que de coder plus salement et à reculons dans un langage Y pour des raisons de perfos un brin fumeuses

Bin là pareil, j'vois vraiment rien de choquant dans les tris de Arrays Pourtant, c'est un truc que j'utilise beaucoup, notamment pour faire de la compression de fichier texte et les perfos sont plus qu'honorables...

Taiche, détends-toi.
 
1. Je parlais pas de Perl, c'est pas mon rayon, mais plutôt d'un shell script ou d'un awk ou d'une combinaison;
 
2. La quantité de code sachant 1. : évident !!!!! Ouverture du fichier et même boucle pour le lire peuvent être implicites, ça commence déjà mal en java (et sûrement dans d'autres langages).
 
3. Sur les perf, beh, dans certains cas ça peut être pas dégueu en java, mais souvent c'est relou. Le SORT étant le cas extrême - mais pourtant quoi de plus banal qu'un tri de fichier.
 
Si j'ai un cas concret sous la main ? Non, j'ai expérimenté ça par le passé. Mais bien entendu les contre-arguments sont bienvenus, on peut faire des comparaisons pour les convaincus comme pr les sceptiques.

Prends un fichier de qq megas et fais un tri en java. Compare avec un SORT sous unix.
 
* Lignes de code ? 1 pour le sort, cb en java ?
 
* Vitesse ? La dernière fois qu'on l'a fait au boulot, on avait un ordre de grandeur en minutes en java et en 2-5 secondes avec sort.

 
Incroyable.

 
vous deviez utiliser un container java mal adapté au tri pour obtenir un différence de cette ordre (10* moins rapide), c'est sur

T'inquiète, chu détendu, là

Alors dans ce cas, c'est pour moi une vision un peu erronée. Le script consiste à appeler des programmes qui font les traitements pour toi.
Ca reviendrait à dire : "ce que tu fais avec ls -l | grep youpi | awk {print $1;}, ba j'le fais avec java Youpi, donc le scripting cai mal ça prend plus de place"

Ba ui mais c'est c'que j'dis au-dessus : j'utilise des tonnes de fois Arrays.sort() dans ma classe de compression de données (via Huffman) et côté perfos, j'dois compresser un fichier de 10 Mo en un truc genre 700 ms sur mon pôv Athlon 2000+@1367 MHz
Après, même si on me démontrait par A+B que c'est plus rapide, j'irais pas me casser le cul à tout réécrire en Perl pour gagner ne serait-ce que 20% en perfs.

Ba j'veux bien, ui, ne serait-ce que pour comprendre où Java serait mauvais et pourquoi (si jamais c'est le cas).

plop

Ba pareil : java.util.Arrays.sort(monJouliTableau);

Bin vala, spour ça que j'demande à voir la tronche du test : type et nombre de données dans le tableau, algo utilisé, etc...

vous battez pas les filles, je demandais
 
suis en train de faire une petite classe aevc une methode, je posterais le code pour que vous corrigiez et les perfs, et demain je ferais le perl ou un bash, histoire de voir.
 
meme si java me convient, je bouffe assez de script comme ca toute la journee, faire un peu de java m'ira parfaitement

Les gars, on peut se faire un retest sur un exemple concret. Mais sur le coup du tri, là, je suis prêt à miser.
 
Taiche: ta remarque sur la quantité de code est spécieuse ceci étant dit. On parle bien du code qu'il faut pisser dans l'un ou l'autre cas, pas de l'invocation, qui peut tjs se réduire à un appel trivial "zyva.sh".
 
schnapsmann: qu'est-ce que appelle "container java mal adapté au tri" ? Tu veux dire que le container est d'office mal adapté ou que _ce_ container là aurait pu être mal adapté ?
 
On va de toute façon faire des tests éventuels hors containers, hein !
 
uriel: fait pêter la sauce. Un tri, un tri !

OK, mais dans ce cas, qu'appelles-tu "sort UNIX" ? Si tu parles de la commande sort, ba c'est un programme compilé à la base, spa un truc tout magique sorti de nulle part
Donc au niveau "pissage de code" pour le développeur final, c'est pareil dans les deux cas : sort machin ou Arrays.sort(machin). Après, si tu parles de l'algo qui est derrière, ba j'vois pas pourquoi faudrait se casser à réinventer la roue

Taiche, envoie ton code pour trier un fichier. Je vais l'exécuter et comparer avec 'sort'.

non, mais c'etait juste une question hein

Je prends ça très à coeur.  

Skoi "trier un fichier" ? Tu peux être plus précis et filer un sample de fichier à trier ?
 
Uriel : ça t'apprendra à lâcher des trolls

Ouais, uriel, la prochaine fois, abstiens-toi
 
Trier un fichier ? Beh c'est 'trier' un 'fichier'. C'est une question piège ?
 
Par exemple :
 
baba
ahah
xouxou
 
après tri :
 
ahah
baba
xouxou
java.lang.NullPointerException
 
Filer un sample : beh non, pour tester, faut un fichier conséquent, pas un comme ci-dessus. Tu peux le générer random en java - et on ne va pas pousser le vice pour savoir quel outil ou langage est le plus adapté pour le générer, ok uriel ?

moi, je peux jouer ?

Heu, beh oui, c'est un forum ouvert

on trie des caractères monobytes dans l'ordre lexicographique ? en utilisant ascii (enfin isobidule-machin) pour l'ordre de lettre dans l'alphabet ?
 
on trie les lignes délimitées par \n

Tu veux bien arrêter de faire le malin et de parler comme un érudit   ?

 
voici une mauvaise implementation en c++ pour donner une chance au java

bah bah bah  
 
#   while(cin)
#   {
#     getline(cin, line);
 
->
 
#   while(getline(cin, line))
 
 
le reste c'est bien.

ouais mais c'est toujour aussi lent

j'aurais tendance à dire que c'est les E/S qui puxor
 
et tout le monde s'en fout de mon problème de boxing

implémentation de base

toute ressemblance avec un code tapé à la volée, sans vérification que ca compile ou que ca marche ne serait que pure imagination de votre part