Tu as des chiffres ? Tu parles de gcc ? De clang ?
Tu build ton projet avec make avec des règles du genre :
fic.o:fic.hfic.c
cc...
Pour chaque fichier que tu génère tu lance ton compilateur. Ce n'est pas péremptoire, mais un fait.
C'est juste une impression personnelle ou les développeurs Java ont une forte tendance à dire que ce que Java ne fait pas n'a pas d'intérêt ?
Pas du tout, Java a pleins de problèmes. Je peux te parler du go si tu préfère. En go tu n'a autant besoin de faire de la parallélisation parce que tu lance une fois ton compilateur pour l'ensemble de tes sources. javac est très rapide (et vu le peu de chose qu'on lui demande de faire c'est encore heureux) là où gcc est très lent comparativement parce qu'il ne traite q'une seule unité de compilation par lancement, parce que la manière de gérer les entête par inclusion est très lente. En c++ c'est encore pire si tu utilise les templates de manière un peu poussée.
Mais je suis d'avis qu'il vaut mieux une compilation un peu plus lente et une vitesse d'exécution d'enfer que l'inverse.
Les rares fois où j'ai été obligé d'utiliser Maven, c'est justement là où je me suis dit que la perf peut vraiment avoir une importance dans un système de build. C'est abominablement lent...
La parallélisation ne changera rien. Maven n'est pas très rapide parce qu'il est con, parce qu'il n'a pas de cache entre chaque lancement, parce que les dev s'en foutent,... Ce n'est pas un problème de parallélisme. Intéresse toi à la question, tu verra de toi même ce n'est pas la parallélisation qui le ralenti.
Faut pas se focaliser, la parallélisation n'est pas la seule réponse à la lenteur.
Tiens au fait pour ton troll. Il y a pas mal de projet C++ qui prennent en compte la performance de leur build lors du développement (en limitant le nombre de fichiers, en effectuant plus de choses directement dans les headers, en modifiant leur build pour utiliser des entêtes précompilées,...), je n'ai jamais vu un projet en java avoir besoin de ce genre de chose (mais remplace java par go dans tout ce que je dis ça restera vrai).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: $(SHELL)
Posté par barmic . En réponse au journal Utiliser Python comme interpréteur dans vos Makefile. Évalué à 6.
Tu build ton projet avec make avec des règles du genre :
Pour chaque fichier que tu génère tu lance ton compilateur. Ce n'est pas péremptoire, mais un fait.
Pas du tout, Java a pleins de problèmes. Je peux te parler du go si tu préfère. En go tu n'a autant besoin de faire de la parallélisation parce que tu lance une fois ton compilateur pour l'ensemble de tes sources. javac est très rapide (et vu le peu de chose qu'on lui demande de faire c'est encore heureux) là où gcc est très lent comparativement parce qu'il ne traite q'une seule unité de compilation par lancement, parce que la manière de gérer les entête par inclusion est très lente. En c++ c'est encore pire si tu utilise les templates de manière un peu poussée.
Mais je suis d'avis qu'il vaut mieux une compilation un peu plus lente et une vitesse d'exécution d'enfer que l'inverse.
La parallélisation ne changera rien. Maven n'est pas très rapide parce qu'il est con, parce qu'il n'a pas de cache entre chaque lancement, parce que les dev s'en foutent,... Ce n'est pas un problème de parallélisme. Intéresse toi à la question, tu verra de toi même ce n'est pas la parallélisation qui le ralenti.
Faut pas se focaliser, la parallélisation n'est pas la seule réponse à la lenteur.
Tiens au fait pour ton troll. Il y a pas mal de projet C++ qui prennent en compte la performance de leur build lors du développement (en limitant le nombre de fichiers, en effectuant plus de choses directement dans les headers, en modifiant leur build pour utiliser des entêtes précompilées,...), je n'ai jamais vu un projet en java avoir besoin de ce genre de chose (mais remplace java par go dans tout ce que je dis ça restera vrai).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)