Le plus rapide : C ou Perl ?

Charlie Gordon

29/09/2005 à 10:57

"Nanard" wrote in message
news:

Bonjour

Je suis sur Solaris 9.
J'ai qques scripts Bash, et Perl qui font des trucs long et toutes les
heures. Ca marche assez bien.

If it ain't broke don't fix it !

Mais bon, que ce soit en Perl ou en Bash, je lance souvent (en boucle)
des commandes de l'OS : 'echo' 'cp' 'mv' 'ssh' 'ftp' sftp' 'sqlplus'
... donc en fait ma solution n'est pas super optimisee : a chaque fois
l'OS alloue un shell (thread/RAM/pile...) teste mes parametres, exec la

fonction et libere tout ca avant de rendre la main a mon script.

Oui, mais cet overhead est minime en regard de ce que font certaines de ces
commandes : ftp, ssh, sqlplus...
Tu peux sans doute optimiser les 'echo' et autres mv, mais c'est possible que
perl le fasse déjà sans passer par le shell.

Je pense qu'en C se serait 1000 fois + rapide...

Sans doute pas à cause de ce genre de choses. Si tu fais des calculs longs et
compliqués, c'est possible.
Si ces trucs sont longs, ce n'est pas nécessairement à cause du langage, ni du
fait d'appeler des commandes par le shell, une session ftp peut prendre du temps
sans vraiment charger la machine.

Comme j'ai un peux de temps, et d'autres projets du meme style qui
arrivent, ma question :
- dois-je tout porter en C (me faire des fonctions, structs, squelette
app.)

Mauvaise idée

- dois-je explorer + en detail les lib Perl (qui sont en Standard sur
Solaris 9).

Pas très utile non plus.

- Perl est-il compile a la volee, ou tout le temps interprete ? J'ai
l'impression que c'est un peux comme Java, me trompe-je ?

Je pense qu'il est compilé en byte code, un peu comme java.

Il y a certains trucs que je sais pas faire en Perl (exec .profile,
SQL...) et puis je ne sais pas trop quelles lib sont installee en
standard sur Solaris... c'est pour ca que je passe par Bash et meme en
Perl je lance des commandes de l'OS (sqlplus, ftp, sftp).

Optimiser ces scripts n'a pas beaucoup d'intérêt s'ils sont fonctionnels et
chargent peu la machine.

Réécrire en C des trucs qui s'expriment mieux en bash ou en perl prendrait
beaucoup de temps, avec des tas de bugs potentiels, et serait meme difficile si
tu executes d'autres commandes : il faut gérer les signaux, faire à la main des
fork, exec, et autres constructions de ligne de commande, sans parler des
patterns du shell... Une vraie galère.

--
Chqrlie.

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

"Nanard" <bsegonnes@free.fr> wrote in message
news:1127983284.813829.198600@g49g2000cwa.googlegroups.com...

Bonjour

Je suis sur Solaris 9.
J'ai qques scripts Bash, et Perl qui font des trucs long et toutes les
heures. Ca marche assez bien.

If it ain't broke don't fix it !

Mais bon, que ce soit en Perl ou en Bash, je lance souvent (en boucle)
des commandes de l'OS : 'echo' 'cp' 'mv' 'ssh' 'ftp' sftp' 'sqlplus'
... donc en fait ma solution n'est pas super optimisee : a chaque fois
l'OS alloue un shell (thread/RAM/pile...) teste mes parametres, exec la

fonction et libere tout ca avant de rendre la main a mon script.

Oui, mais cet overhead est minime en regard de ce que font certaines de ces
commandes : ftp, ssh, sqlplus...
Tu peux sans doute optimiser les 'echo' et autres mv, mais c'est possible que
perl le fasse déjà sans passer par le shell.

Je pense qu'en C se serait 1000 fois + rapide...

Sans doute pas à cause de ce genre de choses. Si tu fais des calculs longs et
compliqués, c'est possible.
Si ces trucs sont longs, ce n'est pas nécessairement à cause du langage, ni du
fait d'appeler des commandes par le shell, une session ftp peut prendre du temps
sans vraiment charger la machine.

Comme j'ai un peux de temps, et d'autres projets du meme style qui
arrivent, ma question :
- dois-je tout porter en C (me faire des fonctions, structs, squelette
app.)

Mauvaise idée

- dois-je explorer + en detail les lib Perl (qui sont en Standard sur
Solaris 9).

Pas très utile non plus.

- Perl est-il compile a la volee, ou tout le temps interprete ? J'ai
l'impression que c'est un peux comme Java, me trompe-je ?

Je pense qu'il est compilé en byte code, un peu comme java.

Il y a certains trucs que je sais pas faire en Perl (exec .profile,
SQL...) et puis je ne sais pas trop quelles lib sont installee en
standard sur Solaris... c'est pour ca que je passe par Bash et meme en
Perl je lance des commandes de l'OS (sqlplus, ftp, sftp).

Optimiser ces scripts n'a pas beaucoup d'intérêt s'ils sont fonctionnels et
chargent peu la machine.

Réécrire en C des trucs qui s'expriment mieux en bash ou en perl prendrait
beaucoup de temps, avec des tas de bugs potentiels, et serait meme difficile si
tu executes d'autres commandes : il faut gérer les signaux, faire à la main des
fork, exec, et autres constructions de ligne de commande, sans parler des
patterns du shell... Une vraie galère.

--
Chqrlie.

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

Vous avez filtré cet utilisateur ! Consultez son message

"Nanard" wrote in message
news:

Bonjour

Je suis sur Solaris 9.
J'ai qques scripts Bash, et Perl qui font des trucs long et toutes les
heures. Ca marche assez bien.

If it ain't broke don't fix it !

Mais bon, que ce soit en Perl ou en Bash, je lance souvent (en boucle)
des commandes de l'OS : 'echo' 'cp' 'mv' 'ssh' 'ftp' sftp' 'sqlplus'
... donc en fait ma solution n'est pas super optimisee : a chaque fois
l'OS alloue un shell (thread/RAM/pile...) teste mes parametres, exec la

fonction et libere tout ca avant de rendre la main a mon script.

Oui, mais cet overhead est minime en regard de ce que font certaines de ces
commandes : ftp, ssh, sqlplus...
Tu peux sans doute optimiser les 'echo' et autres mv, mais c'est possible que
perl le fasse déjà sans passer par le shell.

Je pense qu'en C se serait 1000 fois + rapide...

Sans doute pas à cause de ce genre de choses. Si tu fais des calculs longs et
compliqués, c'est possible.
Si ces trucs sont longs, ce n'est pas nécessairement à cause du langage, ni du
fait d'appeler des commandes par le shell, une session ftp peut prendre du temps
sans vraiment charger la machine.

Comme j'ai un peux de temps, et d'autres projets du meme style qui
arrivent, ma question :
- dois-je tout porter en C (me faire des fonctions, structs, squelette
app.)

Mauvaise idée

- dois-je explorer + en detail les lib Perl (qui sont en Standard sur
Solaris 9).

Pas très utile non plus.

- Perl est-il compile a la volee, ou tout le temps interprete ? J'ai
l'impression que c'est un peux comme Java, me trompe-je ?

Je pense qu'il est compilé en byte code, un peu comme java.

Il y a certains trucs que je sais pas faire en Perl (exec .profile,
SQL...) et puis je ne sais pas trop quelles lib sont installee en
standard sur Solaris... c'est pour ca que je passe par Bash et meme en
Perl je lance des commandes de l'OS (sqlplus, ftp, sftp).

Optimiser ces scripts n'a pas beaucoup d'intérêt s'ils sont fonctionnels et
chargent peu la machine.

Réécrire en C des trucs qui s'expriment mieux en bash ou en perl prendrait
beaucoup de temps, avec des tas de bugs potentiels, et serait meme difficile si
tu executes d'autres commandes : il faut gérer les signaux, faire à la main des
fork, exec, et autres constructions de ligne de commande, sans parler des
patterns du shell... Une vraie galère.

--
Chqrlie.

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

Stephane Zuckerman

29/09/2005 à 13:12

- Perl est-il compile a la volee, ou tout le temps interprete ? J'ai
l'impression que c'est un peux comme Java, me trompe-je ?

Je pense qu'il est compilé en byte code, un peu comme java.

Oui. Il y a une sorte compilation "just in time", avec du bytecode à la
clé.

Réécrire en C des trucs qui s'expriment mieux en bash ou en perl
prendrait beaucoup de temps, avec des tas de bugs potentiels, et serait
meme difficile si tu executes d'autres commandes : il faut gérer les
signaux, faire à la main des fork, exec, et autres constructions de
ligne de commande, sans parler des patterns du shell... Une vraie
galère.

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

Houla. Je serais tenté de dire "trop gros, passera pas".
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Pierre Habouzit

29/09/2005 à 14:15

Stephane Zuckerman wrote:

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

Houla. Je serais tenté de dire "trop gros, passera pas".

Pourtant perl c'est trop gros, trop laid, trop moche, trop lent, trop
chiant, trop peu lisible, trop merdique, et pourtant c'est passé ...
--
·O· Pierre Habouzit
··O
OOO http://www.madism.org

Stephane Zuckerman

29/09/2005 à 15:44

On Thu, 29 Sep 2005, Pierre Habouzit wrote:

Stephane Zuckerman wrote:

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

Houla. Je serais tenté de dire "trop gros, passera pas".

Pourtant perl c'est trop gros, trop laid, trop moche, trop lent, trop
chiant, trop peu lisible, trop merdique, et pourtant c'est passé ...

Oui enfin j'ai déjà entendu ce discours à propos de C, justement. Dire
d'un langage qu'il est "trop peu lisible" alors que sa structuration
s'inspire fortement de C est un peu énorme, je trouve. La structuration
d'un programme dépend du programmeur. Si on veut forcer le programmeur à
assumer une certaine structuration dans son code, on fait du Pascal, de
l'Ada, du Python...

Quant à la vitesse d'exécution de Perl, il est certes beaucoup plus lent
que C (et personne n'osera contredire, et certainement pas ses concepteurs
!), mais en termes de rapidité de développement, il n'y a pas photo, ça va
plus vite avec Perl. Sans parler du fait que dans beaucoup de cas, la
rapidité d'exécution n'est clairement pas un critère majeur pour une
application donnée. Je passe aussi sur les programmes C mal conçus,
rapiécés, qui du coup deviennent de vraies usines à gaz, et qui finalement
sont moins performants qu'un programme écrit dans un autre langage
théoriquement moins rapide à l'exécution (Perl, Python, Ruby, Java, ...),
mais mieux conçu au départ.

Je passe sur les adjectifs "moche", "chiant", "merdique" qui sont purement
subjectifs.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Pierre Habouzit

29/09/2005 à 15:54

Stephane Zuckerman wrote:

On Thu, 29 Sep 2005, Pierre Habouzit wrote:
Stephane Zuckerman wrote:

PS: Si perl n'existait pas, il ne faudrait pas l'inventer.

Houla. Je serais tenté de dire "trop gros, passera pas".

Pourtant perl c'est trop gros, trop laid, trop moche, trop lent, trop
chiant, trop peu lisible, trop merdique, et pourtant c'est passé ...

Oui enfin j'ai déjà entendu ce discours à propos de C, justement. Dire
d'un langage qu'il est "trop peu lisible" alors que sa structuration
s'inspire fortement de C est un peu énorme, je trouve. La structuration
d'un programme dépend du programmeur. Si on veut forcer le programmeur à
assumer une certaine structuration dans son code, on fait du Pascal, de
l'Ada, du Python...

non, le design de perl fait que les programmeurs perl écrivent des trucs du
genre :

while (<>) {
print $_ unless /toto/;
}

Il est possible de "bien" écrire du perl (et encore, je vais faire faire une
crise cardiaque à Chqrlie en disant ca), mais le perl lui même est à chier
par conception.

Je passe sur les adjectifs "moche", "chiant", "merdique" qui sont purement
subjectifs.

désolé, mais des trucs du genre :

$| = 1;

qui veut dire que le dernier fichier ouvert va être ouvert en mode
synchrone, c'est vachement élégant, c'est évident ... </ironie>

Perl est un langage qui sous des prétextes fallacieux de concision pousse à
écrire des horreurs syntaxiques. Perl est par essence un langage
Write-Only. Il m'est (rarement) arrivé d'écrire du perl. Lorsque je relis
ces scripts plus d'un mois apres, il me faut plus de temps pour les
comprendre que pour les récrire.

Et pourtant j'utilise au strict minimum les abominations $[caractère], ou
les arguments `$_' implicites.

--
·O· Pierre Habouzit
··O
OOO http://www.madism.org

Stephane Zuckerman

29/09/2005 à 16:16

non, le design de perl fait que les programmeurs perl écrivent des trucs du
genre :

while (<>) {
print $_ unless /toto/;
}

Ah non, si on va dans ce sens, ce sera plutôt :

while (<>) { print unless /toto/; }

D'un autre côté, quand il s'agit d'écrire des _applications_ en Perl, on a
plutôt tendance à écrire

while (my $line = <>)
{
print $line unless ($line =~ /toto/);
}

Et là je trouve que c'est tout à fait lisible.

Et puis bon, honnêtement, même L. Wall insiste bien sur le fait que les
variables "automatiques" ($_, etc.) n'ont été créées que pour les
sysadmins pressés qui font des scripts vite écrits, vite jetés.

Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses
idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces
soi-disant nouveaux langages qui sont révolutionnaires, mais qui
empruntent tout à C ou C++, et ne font finalement que changer les
mots-clef.

Il est possible de "bien" écrire du perl (et encore, je vais faire faire une
crise cardiaque à Chqrlie en disant ca), mais le perl lui même est à chier
par conception.

Pas d'accord, mais bon.

Je passe sur les adjectifs "moche", "chiant", "merdique" qui sont purement
subjectifs.

désolé, mais des trucs du genre :

$| = 1;

qui veut dire que le dernier fichier ouvert va être ouvert en mode
synchrone, c'est vachement élégant, c'est évident ... </ironie>

use English;

Si ce n'est qu'une histoire de signification des variables "implicites",
ce module est justement là pour tout expliciter.

Sinon, je persiste : il existe certaines formes idiomatiques pour chaque
langage, et j'estime que se souvenir d'en gros quatre variables
importantes ($_, @_, $?, $/) n'est pas la mort. Sinon, je me répète : le
module English est là pour ça.

Perl est un langage qui sous des prétextes fallacieux de concision pousse à
écrire des horreurs syntaxiques. Perl est par essence un langage
Write-Only.

Il m'est (rarement) arrivé d'écrire du perl. Lorsque je relis
ces scripts plus d'un mois apres, il me faut plus de temps pour les
comprendre que pour les récrire.

Normal, vous n'écrivez du Perl qu'occasionnellement. Lorsqu'on écrit du
Perl régulièrement, et si le programme respecte un minimum de règles quant
à la présentation du code, on s'y retrouve plutôt bien.

Et pourtant j'utilise au strict minimum les abominations $[caractère], ou
les arguments `$_' implicites.

Oui, c'est normalement comme ça qu'il faut faire (sauf quand certaines
constructions l'empêchent, bien sûr -- par exemple, map{} ne le permet
pas).

Bref. Retour à fclc. :-)

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

non, le design de perl fait que les programmeurs perl écrivent des trucs du
genre :

while (<>) {
print $_ unless /toto/;
}

Ah non, si on va dans ce sens, ce sera plutôt :

while (<>) { print unless /toto/; }

D'un autre côté, quand il s'agit d'écrire des _applications_ en Perl, on a
plutôt tendance à écrire

while (my $line = <>)
{
print $line unless ($line =~ /toto/);
}

Et là je trouve que c'est tout à fait lisible.

Et puis bon, honnêtement, même L. Wall insiste bien sur le fait que les
variables "automatiques" ($_, etc.) n'ont été créées que pour les
sysadmins pressés qui font des scripts vite écrits, vite jetés.

Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses
idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces
soi-disant nouveaux langages qui sont révolutionnaires, mais qui
empruntent tout à C ou C++, et ne font finalement que changer les
mots-clef.

Il est possible de "bien" écrire du perl (et encore, je vais faire faire une
crise cardiaque à Chqrlie en disant ca), mais le perl lui même est à chier
par conception.

Pas d'accord, mais bon.

Je passe sur les adjectifs "moche", "chiant", "merdique" qui sont purement
subjectifs.

désolé, mais des trucs du genre :

$| = 1;

qui veut dire que le dernier fichier ouvert va être ouvert en mode
synchrone, c'est vachement élégant, c'est évident ... </ironie>

use English;

Si ce n'est qu'une histoire de signification des variables "implicites",
ce module est justement là pour tout expliciter.

Sinon, je persiste : il existe certaines formes idiomatiques pour chaque
langage, et j'estime que se souvenir d'en gros quatre variables
importantes ($_, @_, $?, $/) n'est pas la mort. Sinon, je me répète : le
module English est là pour ça.

Perl est un langage qui sous des prétextes fallacieux de concision pousse à
écrire des horreurs syntaxiques. Perl est par essence un langage
Write-Only.

Il m'est (rarement) arrivé d'écrire du perl. Lorsque je relis
ces scripts plus d'un mois apres, il me faut plus de temps pour les
comprendre que pour les récrire.

Normal, vous n'écrivez du Perl qu'occasionnellement. Lorsqu'on écrit du
Perl régulièrement, et si le programme respecte un minimum de règles quant
à la présentation du code, on s'y retrouve plutôt bien.

Et pourtant j'utilise au strict minimum les abominations $[caractère], ou
les arguments `$_' implicites.

Oui, c'est normalement comme ça qu'il faut faire (sauf quand certaines
constructions l'empêchent, bien sûr -- par exemple, map{} ne le permet
pas).

Bref. Retour à fclc. :-)

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Vous avez filtré cet utilisateur ! Consultez son message

non, le design de perl fait que les programmeurs perl écrivent des trucs du
genre :

while (<>) {
print $_ unless /toto/;
}

Ah non, si on va dans ce sens, ce sera plutôt :

while (<>) { print unless /toto/; }

D'un autre côté, quand il s'agit d'écrire des _applications_ en Perl, on a
plutôt tendance à écrire

while (my $line = <>)
{
print $line unless ($line =~ /toto/);
}

Et là je trouve que c'est tout à fait lisible.

Et puis bon, honnêtement, même L. Wall insiste bien sur le fait que les
variables "automatiques" ($_, etc.) n'ont été créées que pour les
sysadmins pressés qui font des scripts vite écrits, vite jetés.

Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses
idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces
soi-disant nouveaux langages qui sont révolutionnaires, mais qui
empruntent tout à C ou C++, et ne font finalement que changer les
mots-clef.

Il est possible de "bien" écrire du perl (et encore, je vais faire faire une
crise cardiaque à Chqrlie en disant ca), mais le perl lui même est à chier
par conception.

Pas d'accord, mais bon.

Je passe sur les adjectifs "moche", "chiant", "merdique" qui sont purement
subjectifs.

désolé, mais des trucs du genre :

$| = 1;

qui veut dire que le dernier fichier ouvert va être ouvert en mode
synchrone, c'est vachement élégant, c'est évident ... </ironie>

use English;

Si ce n'est qu'une histoire de signification des variables "implicites",
ce module est justement là pour tout expliciter.

Sinon, je persiste : il existe certaines formes idiomatiques pour chaque
langage, et j'estime que se souvenir d'en gros quatre variables
importantes ($_, @_, $?, $/) n'est pas la mort. Sinon, je me répète : le
module English est là pour ça.

Perl est un langage qui sous des prétextes fallacieux de concision pousse à
écrire des horreurs syntaxiques. Perl est par essence un langage
Write-Only.

Il m'est (rarement) arrivé d'écrire du perl. Lorsque je relis
ces scripts plus d'un mois apres, il me faut plus de temps pour les
comprendre que pour les récrire.

Normal, vous n'écrivez du Perl qu'occasionnellement. Lorsqu'on écrit du
Perl régulièrement, et si le programme respecte un minimum de règles quant
à la présentation du code, on s'y retrouve plutôt bien.

Et pourtant j'utilise au strict minimum les abominations $[caractère], ou
les arguments `$_' implicites.

Oui, c'est normalement comme ça qu'il faut faire (sauf quand certaines
constructions l'empêchent, bien sûr -- par exemple, map{} ne le permet
pas).

Bref. Retour à fclc. :-)

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Nanard

29/09/2005 à 17:47

En gros mes scripts :
- bash qui fait du FTP ou SFTP en boucle pour ne recupere QUE certains
fichiers. Des qu'un fichier est copie, on fait des trucs, et ensuite
refait le FTP pour le prochain... C'a fait pas mal de
connexion/deconnexion FTP/SFTP tout ca ! Une seule que l'on pourrait
conserver ferait gagner du temps ?

- Un autre script PERL : convertis ces ficheirs dans un autre format.
Utilisation 'en boucle' des commandes systemes : 'gunzip', ... bon, la
la vitesse est 'correcte.

- un autre en Bash qui renvois les fichiers convertis : meme pb que
precedement : je fais une connexion FTP par transfert, et qques trucs
entre les transferts.

- un autre Bash + Perl : qui lancent Sqlplus, charge ".profile"
d'oracle,...
Ne serait-ce pas mieux de faire du SQL 'directement' en Perl ?

Je suis alle faire un tour sur http://search.cpan.org ou j'ai recupere
pliens de lib. Perl.
J'en ai teste une au hasard : FTP. J'ai recopie le FTP.pm
Et bien, il faut des dependances... j'en ai copie a la main, il en
manque d'autres (qu'ils faudrait installer avec le prog de config).
Bref, on n'en sort plus !!!! Comme sur Linux :-)

Je voudrais bien faire le truc le pls simple et leger possible et qui
marche partout (Solaris !), il semble que ce soit encore ma solution :
appeler des commandes systemes :-(

R12y

29/09/2005 à 18:45

On Thu, 29 Sep 2005 08:47:47 -0700, Nanard wrote:

J'en ai teste une au hasard : FTP. J'ai recopie le FTP.pm
Là, ça n'a rien à faire ici.

Ce n'est pas le fichier .pm que tu dois télécharger mais le tarball.
Il y a un groupe spécial pour Perl.
Bon courage.

--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/

Harpo

29/09/2005 à 21:42

Nanard wrote:

Bonjour

Je suis sur Solaris 9.
J'ai qques scripts Bash, et Perl qui font des trucs long et toutes les
heures. Ca marche assez bien.
Mais bon, que ce soit en Perl ou en Bash, je lance souvent (en boucle)
des commandes de l'OS : 'echo' 'cp' 'mv' 'ssh' 'ftp' sftp' 'sqlplus'
... donc en fait ma solution n'est pas super optimisee : a chaque fois
l'OS alloue un shell (thread/RAM/pile...) teste mes parametres, exec
la fonction et libere tout ca avant de rendre la main a mon script.

Je pense qu'en C se serait 1000 fois + rapide...

N'exagérons rien, disons à peine plus, et encore... Le temps pour
lancer un process est du à la création d'un espace d'adressage etc.
Qu'ily ait 10 fois plus d'instructions exécutées avant est dérisoire.
Ca vous permettrait peut-être de gagner quelques milli-secondes toutes
les heures. Disons une seconde dans l'année.

Bon maintenant, allez expliquer à l'ingénieur système qu'il faut qu'il
fasse des programmes en C plutôt que d'écrire des scripts, vous le
conduisez au suicide à moins qu'il ne soit déjà fou.

Les langages ont leur vocation, les utiliser en dehors de celle-ci n'est
pas une bonne idée.
Bash est correct, un peu lent mais bon pour des choses assez simples.
Perl est plus rapide, un peu ennuyeux à la lecture mais plus clair
qu'une expression régulière avec des mixins Lisp non indentés.
Je ne peux que vous conseiller Ruby, un langage de script complètement
orienté objet, un bijou ! Un peu plus lent que Perl certes, mais un
vrai bon langage.

Comme j'ai un peux de temps, et d'autres projets du meme style qui
arrivent, ma question :
- dois-je tout porter en C (me faire des fonctions, structs, squelette
app.)

Tu fais comme tu sens, mais moi je ne le sens pas. Pas du tout.
Avant de faire quelque chose, il faut en mesurer l'enjeu, ici j'ai peur
qu'il n'y en ait aucun.

Harpo

29/09/2005 à 23:25

Nanard wrote:

Je pense qu'en C se serait 1000 fois + rapide...

Si tu veux que ton système soit performant, c'est le genre de question à
se poser quand tout le reste est réglé.
Pose-toi plutôt des questions du genre : Où est le bottleneck ? Où sont
mes partitions de swap ? sur quel controller, quel disque, Y a-t-il
autre chose sur ces disques ? Quoi ? quelles sont les contentions. etc.
Enfin ce genre de questions. Savoir si un script exécuté toutes les
heures serait mieux en C ou en Perl, c'est vraiment qu'on n'a plus rien
à faire et même une journée de travail là dessus pour gagner des
cacahouettes ne vaut pas le prix d'un disque SCSI.

Le plus rapide : C ou Perl ?

10 réponses

Veuillez sélectionner un problème