Le segment de code suivant prend plus de temps (5s) lorsqu'il est exécuté pour la première fois et prend moins de temps (250 ms) lors des exécutions consécutives. Existe-t-il un meilleur moyen d'exécuter gcc.Une meilleure alternative à fork(), puis execvp ("gcc program.c")?
int pid,status;
char * argv[] = {"gcc","program.c",NULL};
if(!(pid=fork())){
execvp("gcc",argv);
}
while(pid!=wait(&status)){
//do nothing
}
Il n'y a pas d'autre moyen de le faire pour différentes versions d'Unix. Pour exécuter un processus séparé, vous devez utiliser fork-exec - c'est exactement pour cela qu'ils sont faits.
Il y a aussi posix_spawn: https://www.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html :-P –
Eh bien, je ne pense pas. 5 secondes sur le premier coup est probablement le temps de tout lire du disque à la mémoire. Le compilateur lui-même, les sources à compiler, les en-têtes à inclure, les bibliothèques à lier, etc. Il est dispersé sur tout le disque, donc les têtes de disques doivent chercher beaucoup. C'est lent. Après que vous avez toutes les données mises en cache dans la RAM, c'est juste l'analyse et la compilation et devient probablement CPU boudn plutôt que disque E/S lié.
Y at-il un moyen que je puisse avoir toutes les données nécessaires par GCC mis en cache dans la RAM, peu importe Quelle est la gravité des autres processus dans le système? –
Throw matériel au problème. Disque plus rapide. Plus de RAM. Les développeurs ont besoin de bons outils. Vous pouvez optimiser la planification d'E/S de bas niveau. C'est spécifique au système et je n'ai aucune idée de comment le faire sur n'importe quel OS que vous utilisez. –
J'utilise CentOS. –
Il existe d'autres fonctions que vous pouvez appeler (std::system étant un), mais elles finissent généralement par être implémentées comme fork et exec.
Bien sûr, il y a un meilleur moyen ... stylistiquement. Utilisez execlp et vous n'aurez pas besoin du tableau séparé. :-) –