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...
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.)
- dois-je explorer + en detail les lib Perl (qui sont en Standard sur
Solaris 9).
- 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 ?
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).
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. Oui, d'ailleurs, il a un nom : fr.comp.lang.perl
FU2 approprié. -- "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)
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.
Oui, d'ailleurs, il a un nom : fr.comp.lang.perl
FU2 approprié.
--
"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)
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. Oui, d'ailleurs, il a un nom : fr.comp.lang.perl
FU2 approprié. -- "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
Ce qui est marrant avec les news group (pas que ici), c'est qu'il semble y avoir pas mal de professionnel (pas etudiant, ou autres), mais qu'ils pensent que les gens qui posent des questions (les developpeur) aient une influence sur les spec/archi.
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs boites, ma partie est un tout petit truc d'un gros contrat. Les disque, la RAM, etc... : desole : je peut RIEN y faire. Mon 'probleme' est de faire du bon code, qui tourne le mieux possible sur les serveurs qui me sont (pas entierrement) 'alloue'.
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante : je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut que mes scripts marchent le + vite possible (car en prod. ce sera autre chose qu'en dev. la charge !!!)
Voila, c'est tout.
Ce qui est marrant avec les news group (pas que ici), c'est qu'il
semble y avoir pas mal de professionnel (pas etudiant, ou autres), mais
qu'ils pensent que les gens qui posent des questions (les developpeur)
aient une influence sur les spec/archi.
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs
boites, ma partie est un tout petit truc d'un gros contrat. Les
disque, la RAM, etc... : desole : je peut RIEN y faire.
Mon 'probleme' est de faire du bon code, qui tourne le mieux possible
sur les serveurs qui me sont (pas entierrement) 'alloue'.
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante :
je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut
que mes scripts marchent le + vite possible (car en prod. ce sera autre
chose qu'en dev. la charge !!!)
Ce qui est marrant avec les news group (pas que ici), c'est qu'il semble y avoir pas mal de professionnel (pas etudiant, ou autres), mais qu'ils pensent que les gens qui posent des questions (les developpeur) aient une influence sur les spec/archi.
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs boites, ma partie est un tout petit truc d'un gros contrat. Les disque, la RAM, etc... : desole : je peut RIEN y faire. Mon 'probleme' est de faire du bon code, qui tourne le mieux possible sur les serveurs qui me sont (pas entierrement) 'alloue'.
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante : je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut que mes scripts marchent le + vite possible (car en prod. ce sera autre chose qu'en dev. la charge !!!)
Voila, c'est tout.
Stephane Zuckerman
Ce qui est marrant avec les news group (pas que ici), c'est qu'il semble y avoir pas mal de professionnel (pas etudiant, ou autres), mais qu'ils pensent que les gens qui posent des questions (les developpeur) aient une influence sur les spec/archi.
Ce n'est pas qu'une question d'architecture. Il y a (au moins ici) une bonne proportion de gens qui sont des professionnels, et une autre proportion (sans doute moindre parmi ceux qui s'expriment) d'étudiants.
Ta question originale concernant Perl et C a trouvé une réponse non-seulement ici, mais aussi sur fr.comp.lang.perl. Tout le reste (tes problèmes de modules Perl, etc.) n'ont rien à faire ici, sur fclc. C'est pas grave de demander, mais c'est juste totalement hors-sujet. Par contre, ta question initiale ("lier des appels de commandes en C, est-ce pertinent ?") était bien en charte je pense.
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs boites, ma partie est un tout petit truc d'un gros contrat. Les disque, la RAM, etc... : desole : je peut RIEN y faire.
Et personne ne t'a rien dit à ce sujet, à ce que j'ai vu.
Mon 'probleme' est de faire du bon code, qui tourne le mieux possible sur les serveurs qui me sont (pas entierrement) 'alloue'.
Oui, et on t'a répondu (en double, sur deux newsgroups, avec à peu près le même genre de réponse).
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante : je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut que mes scripts marchent le + vite possible (car en prod. ce sera autre chose qu'en dev. la charge !!!)
Etant donné qu'il y aura beaucoup d'entrées-sorties, ce n'est _clairement_pas_ le langage qui sera à l'origine du manque de performances.
-- "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)
Ce qui est marrant avec les news group (pas que ici), c'est qu'il
semble y avoir pas mal de professionnel (pas etudiant, ou autres), mais
qu'ils pensent que les gens qui posent des questions (les developpeur)
aient une influence sur les spec/archi.
Ce n'est pas qu'une question d'architecture. Il y a (au moins ici) une
bonne proportion de gens qui sont des professionnels, et une autre
proportion (sans doute moindre parmi ceux qui s'expriment) d'étudiants.
Ta question originale concernant Perl et C a trouvé une réponse
non-seulement ici, mais aussi sur fr.comp.lang.perl. Tout le reste (tes
problèmes de modules Perl, etc.) n'ont rien à faire ici, sur fclc. C'est
pas grave de demander, mais c'est juste totalement hors-sujet. Par contre,
ta question initiale ("lier des appels de commandes en C, est-ce
pertinent ?") était bien en charte je pense.
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs
boites, ma partie est un tout petit truc d'un gros contrat. Les
disque, la RAM, etc... : desole : je peut RIEN y faire.
Et personne ne t'a rien dit à ce sujet, à ce que j'ai vu.
Mon 'probleme' est de faire du bon code, qui tourne le mieux possible
sur les serveurs qui me sont (pas entierrement) 'alloue'.
Oui, et on t'a répondu (en double, sur deux newsgroups, avec à peu près le
même genre de réponse).
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante :
je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut
que mes scripts marchent le + vite possible (car en prod. ce sera autre
chose qu'en dev. la charge !!!)
Etant donné qu'il y aura beaucoup d'entrées-sorties, ce n'est
_clairement_pas_ le langage qui sera à l'origine du manque de
performances.
--
"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)
Ce qui est marrant avec les news group (pas que ici), c'est qu'il semble y avoir pas mal de professionnel (pas etudiant, ou autres), mais qu'ils pensent que les gens qui posent des questions (les developpeur) aient une influence sur les spec/archi.
Ce n'est pas qu'une question d'architecture. Il y a (au moins ici) une bonne proportion de gens qui sont des professionnels, et une autre proportion (sans doute moindre parmi ceux qui s'expriment) d'étudiants.
Ta question originale concernant Perl et C a trouvé une réponse non-seulement ici, mais aussi sur fr.comp.lang.perl. Tout le reste (tes problèmes de modules Perl, etc.) n'ont rien à faire ici, sur fclc. C'est pas grave de demander, mais c'est juste totalement hors-sujet. Par contre, ta question initiale ("lier des appels de commandes en C, est-ce pertinent ?") était bien en charte je pense.
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs boites, ma partie est un tout petit truc d'un gros contrat. Les disque, la RAM, etc... : desole : je peut RIEN y faire.
Et personne ne t'a rien dit à ce sujet, à ce que j'ai vu.
Mon 'probleme' est de faire du bon code, qui tourne le mieux possible sur les serveurs qui me sont (pas entierrement) 'alloue'.
Oui, et on t'a répondu (en double, sur deux newsgroups, avec à peu près le même genre de réponse).
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante : je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut que mes scripts marchent le + vite possible (car en prod. ce sera autre chose qu'en dev. la charge !!!)
Etant donné qu'il y aura beaucoup d'entrées-sorties, ce n'est _clairement_pas_ le langage qui sera à l'origine du manque de performances.
-- "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)
R12y
On Fri, 30 Sep 2005 00:48:43 -0700, Nanard wrote:
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs boites, ma partie est un tout petit truc d'un gros contrat. Les disque, la RAM, etc... : desole : je peut RIEN y faire.
Donc tu va expliquer à tes employeurs que vu comment le bouzin est fait, tu n'a pas besoin d'optimiser ton code mais que c'est le matériel qu'il faut optimiser :-)
Il serait temps de couper ce fil de discussion, non?
-- 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/
On Fri, 30 Sep 2005 00:48:43 -0700, Nanard wrote:
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs
boites, ma partie est un tout petit truc d'un gros contrat. Les
disque, la RAM, etc... : desole : je peut RIEN y faire.
Donc tu va expliquer à tes employeurs que vu comment le bouzin est fait,
tu n'a pas besoin d'optimiser ton code mais que c'est le matériel qu'il
faut optimiser :-)
Il serait temps de couper ce fil de discussion, non?
--
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/
Je vais parler de mon cas : je suis sur un projet ou il y a plusieurs boites, ma partie est un tout petit truc d'un gros contrat. Les disque, la RAM, etc... : desole : je peut RIEN y faire.
Donc tu va expliquer à tes employeurs que vu comment le bouzin est fait, tu n'a pas besoin d'optimiser ton code mais que c'est le matériel qu'il faut optimiser :-)
Il serait temps de couper ce fil de discussion, non?
-- 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
Nanard wrote:
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante : je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut que mes scripts marchent le + vite possible (car en prod. ce sera autre chose qu'en dev. la charge !!!)
Au sujet de la rapidité, la question est : que font les scripts ? S'ils font des calculs mathématiques longs avec inversions de matrices et des choses qui utilisent beaucoup de CPU, réécrit en C. S'ils font de la rotation de logs ou de la copie de fichiers, ils sont très bien en Perl, le gain d'une réécriture en C serait à peine perceptible. Avant de se lancer dans une réécriture dans un autre langage, il faut d'abord se demander quel gain cela va apporter. J'ai peur qu'on ne puisse t'aider que dans les grandes lignes.
Je ne connais pas ta place dans le projet, je voulais simplement dire qu'en général le débit d'un serveur ne dépend pas beaucoup de ce genre de scripts (à moins qu'ils soient vraiment très lourds), il tient plus à l'OS choisi, la manière dont il a été généré, paramétré etc, pour le serveur idem. Si la rapidité des scripts a une importance certaine, il peut y avoir des critères plus importants comme leur maintenabilité.
Nanard wrote:
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante
: je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut
que mes scripts marchent le + vite possible (car en prod. ce sera
autre chose qu'en dev. la charge !!!)
Au sujet de la rapidité, la question est : que font les scripts ?
S'ils font des calculs mathématiques longs avec inversions de matrices
et des choses qui utilisent beaucoup de CPU, réécrit en C.
S'ils font de la rotation de logs ou de la copie de fichiers, ils sont
très bien en Perl, le gain d'une réécriture en C serait à peine
perceptible.
Avant de se lancer dans une réécriture dans un autre langage, il faut
d'abord se demander quel gain cela va apporter. J'ai peur qu'on ne
puisse t'aider que dans les grandes lignes.
Je ne connais pas ta place dans le projet, je voulais simplement dire
qu'en général le débit d'un serveur ne dépend pas beaucoup de ce genre
de scripts (à moins qu'ils soient vraiment très lourds), il tient plus
à l'OS choisi, la manière dont il a été généré, paramétré etc, pour le
serveur idem.
Si la rapidité des scripts a une importance certaine, il peut y avoir
des critères plus importants comme leur maintenabilité.
Donc, ma question de comparaison de Bash, Perl, C, ... est pertinante : je ne peux pas rajouter toucher au hard/reseaux, et pourtant il faut que mes scripts marchent le + vite possible (car en prod. ce sera autre chose qu'en dev. la charge !!!)
Au sujet de la rapidité, la question est : que font les scripts ? S'ils font des calculs mathématiques longs avec inversions de matrices et des choses qui utilisent beaucoup de CPU, réécrit en C. S'ils font de la rotation de logs ou de la copie de fichiers, ils sont très bien en Perl, le gain d'une réécriture en C serait à peine perceptible. Avant de se lancer dans une réécriture dans un autre langage, il faut d'abord se demander quel gain cela va apporter. J'ai peur qu'on ne puisse t'aider que dans les grandes lignes.
Je ne connais pas ta place dans le projet, je voulais simplement dire qu'en général le débit d'un serveur ne dépend pas beaucoup de ce genre de scripts (à moins qu'ils soient vraiment très lourds), il tient plus à l'OS choisi, la manière dont il a été généré, paramétré etc, pour le serveur idem. Si la rapidité des scripts a une importance certaine, il peut y avoir des critères plus importants comme leur maintenabilité.
Emmanuel Delahaye
Harpo wrote on 29/09/05 :
Nanard wrote:
Je pense qu'en C se serait 1000 fois + rapide...
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
Voilà la bonne réponse.
Question suivante (sur le langage C SVP).
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"It's specified. But anyone who writes code like that should be transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Harpo wrote on 29/09/05 :
Nanard wrote:
Je pense qu'en C se serait 1000 fois + rapide...
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
Voilà la bonne réponse.
Question suivante (sur le langage C SVP).
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre ! En France, on n'a que des goulots d'étranglement.
Merci, c'est le mot que je cherchais, goulot de bouteille n'aurait pas été clair.
Pierre Maurette
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre ! Et même dans quelques autres villages anglophones.
En France, on n'a que des goulots d'étranglement. Goulets ?
Google donne un "goulet d'étranglement" pour deux "goulot d'étranglement". Mais Google ... L'idée de limiter un débit est plus dans goulet que dans goulot. On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
-- Pierre Maurette
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre !
Et même dans quelques autres villages anglophones.
En France, on n'a que des goulots d'étranglement.
Goulets ?
Google donne un "goulet d'étranglement" pour deux "goulot
d'étranglement". Mais Google ...
L'idée de limiter un débit est plus dans goulet que dans goulot. On
doit d'ailleurs pouvoir se passer de "d'étranglement", en restant
clair.
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre ! Et même dans quelques autres villages anglophones.
En France, on n'a que des goulots d'étranglement. Goulets ?
Google donne un "goulet d'étranglement" pour deux "goulot d'étranglement". Mais Google ... L'idée de limiter un débit est plus dans goulet que dans goulot. On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
-- Pierre Maurette
Richard Delorme
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre !
Et même dans quelques autres villages anglophones.
En France, on n'a que des goulots d'étranglement.
Goulets ? Google donne un "goulet d'étranglement" pour deux "goulot d'étranglement". Mais Google ...
L'Académie Française est d'accord avec Google, goulot d'étranglement est le terme le plus usuel.
Dictionnaire de l'Académie Française, 9ème édition :
(1)GOULET n. m. XIVe siècle, au sens de « ruisseau ». Diminutif de goule, ancienne forme de gueule. 1. Vieilli. Col d'une bouteille (on dit aujourd'hui Goulot). 2. Chenal étroit faisant communiquer un port, une rade avec la haute mer. Le goulet de Brest. 3. Passage étroit, resserré entre des rochers, des parois escarpées. Les alpinistes franchirent un goulet. Loc. Goulet d'étranglement, voir Goulot.
GOULOT n. m. XVe siècle, au sens de « passage par où l'eau s'écoule ». Dérivé de goule, ancienne forme de gueule. Col d'une bouteille, d'une carafe ou de tout autre récipient dont l'ouverture est étroite. Le goulot d'un flacon, d'une bouteille. Boire au goulot. Loc. Goulot d'étranglement, sur une voie de communication, passage resserré qui ralentit la circulation des personnes, des véhicules. Se dit figurément de ce qui restreint l'accès à quelque chose et, en termes d'économie, de ce qui entrave les échanges, la croissance ou le développement d'une activité. Une fiscalité trop lourde est un goulot d'étranglement pour l'économie. (On dit parfois Goulet d'étranglement.)
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
Non, il s'agit d'une locution et il faut l'employer en entier.
-- Richard
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre !
Et même dans quelques autres villages anglophones.
En France, on n'a que des goulots d'étranglement.
Goulets ?
Google donne un "goulet d'étranglement" pour deux "goulot
d'étranglement". Mais Google ...
L'Académie Française est d'accord avec Google, goulot d'étranglement est
le terme le plus usuel.
Dictionnaire de l'Académie Française, 9ème édition :
(1)GOULET n. m. XIVe siècle, au sens de « ruisseau ». Diminutif de
goule, ancienne forme de gueule.
1. Vieilli. Col d'une bouteille (on dit aujourd'hui Goulot). 2. Chenal
étroit faisant communiquer un port, une rade avec la haute mer. Le
goulet de Brest. 3. Passage étroit, resserré entre des rochers, des
parois escarpées. Les alpinistes franchirent un goulet. Loc. Goulet
d'étranglement, voir Goulot.
GOULOT n. m. XVe siècle, au sens de « passage par où l'eau s'écoule ».
Dérivé de goule, ancienne forme de gueule.
Col d'une bouteille, d'une carafe ou de tout autre récipient dont
l'ouverture est étroite. Le goulot d'un flacon, d'une bouteille. Boire
au goulot. Loc. Goulot d'étranglement, sur une voie de communication,
passage resserré qui ralentit la circulation des personnes, des
véhicules. Se dit figurément de ce qui restreint l'accès à quelque chose
et, en termes d'économie, de ce qui entrave les échanges, la croissance
ou le développement d'une activité. Une fiscalité trop lourde est un
goulot d'étranglement pour l'économie. (On dit parfois Goulet
d'étranglement.)
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de
limiter le débit, non ?
On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
Non, il s'agit d'une locution et il faut l'employer en entier.
Pose-toi plutôt des questions du genre : Où est le bottleneck ?
En Angleterre !
Et même dans quelques autres villages anglophones.
En France, on n'a que des goulots d'étranglement.
Goulets ? Google donne un "goulet d'étranglement" pour deux "goulot d'étranglement". Mais Google ...
L'Académie Française est d'accord avec Google, goulot d'étranglement est le terme le plus usuel.
Dictionnaire de l'Académie Française, 9ème édition :
(1)GOULET n. m. XIVe siècle, au sens de « ruisseau ». Diminutif de goule, ancienne forme de gueule. 1. Vieilli. Col d'une bouteille (on dit aujourd'hui Goulot). 2. Chenal étroit faisant communiquer un port, une rade avec la haute mer. Le goulet de Brest. 3. Passage étroit, resserré entre des rochers, des parois escarpées. Les alpinistes franchirent un goulet. Loc. Goulet d'étranglement, voir Goulot.
GOULOT n. m. XVe siècle, au sens de « passage par où l'eau s'écoule ». Dérivé de goule, ancienne forme de gueule. Col d'une bouteille, d'une carafe ou de tout autre récipient dont l'ouverture est étroite. Le goulot d'un flacon, d'une bouteille. Boire au goulot. Loc. Goulot d'étranglement, sur une voie de communication, passage resserré qui ralentit la circulation des personnes, des véhicules. Se dit figurément de ce qui restreint l'accès à quelque chose et, en termes d'économie, de ce qui entrave les échanges, la croissance ou le développement d'une activité. Une fiscalité trop lourde est un goulot d'étranglement pour l'économie. (On dit parfois Goulet d'étranglement.)
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
Non, il s'agit d'une locution et il faut l'employer en entier.
