J'examine une implémentation de serveur qui appelle le temps (NULL) pour chaque demande étant traitée. Je me demande quel impact le temps d'appel (NULL) a-t-il sur un système de Linux typique et s'il existe des commandes moins chères pour déterminer le jour - ou en général à quelle fréquence appellez-vous du temps ()?
Merci pour votre opinion sur le sujet.
5 Réponses :
est-ce
Ce n'est sûrement pas un goulot d'étranglement, mais je me demande quel est l'impact en termes de temps de traitement. Je suppose que c'est un appel très optimisé, mais je me demande si quelqu'un a un aperçu clair de cela.
@anselm - Je doute que quiconque ait examiné cette fonction en tant que problème de performance auparavant. Pourquoi ne-tu pas la benchmark?
Je parie que quelqu'un a. Je n'ai jamais regardé le temps spécifiquement, mais je devais vérifier une fois à vérifier les performances de la fonction Java system.getcurrenttimemillis , car un client a affirmé que notre implémentation était un goulot d'étranglement. Ce que ce n'était pas, je pourrais ajouter, ils n'étaient tout simplement pas très bien analysé leur propre code. Mais obtenir le temps système était effectivement lime sur Windows (plusieurs MS IIRC, mais je pourrais me tromper), et je pense plus vite sur Linux. Il y a longtemps, cependant.
C'est juste un seul syscall sans trop de traitement dans le noyau. Le temps () ne fait aucune différence si votre serveur envoie un fichier à l'utilisateur, qui prend 100 () / écrire () s ou fait quelque chose comme ça.
récupération de l'heure actuelle implique un appel système à Linux. Comme sugeded by Vilx, il est assez facile à repasser:
#include <time.h>
int main(void)
{
int i;
for (i = 0; i < 10000000; i++)
time(NULL);
return 0;
}
C'est un appel système, comme les autres réponses, et les autres réponses vous donnent un bon moyen de mesurer le coût de votre système. (Une fois dans le noyau, il ne doit pas nécessairement faire beaucoup de travail, il est donc assez proche du coût de la surcharge de SysCall pure. Et Linux a fait ce qu'il est possible de mettre en œuvre efficacement SysCalls. Donc, vous pouvez le considérer assez bien optimisé.)
Contrairement aux autres réponses, je ne considérerais pas cela si bon marché de ne pas la peine de vous inquiéter. Si cela se trouve dans une boucle intérieure, cela dépend de ce que vous faites d'autre dans votre boucle intérieure. S'il s'agit d'une demande de traitement de serveur, il effectue probablement de nombreux systèmes SysCalls par demande, et une autre ne sera effectivement une modification du coût de chaque demande. Cependant, j'ai vu le code où la surcharge de syscall du temps d'appel () (ou GettimeOfday (), ce qu'il résume vraiment) a un impact préjudiciable.
Si vous êtes inquiet du coût, la prochaine chose à poser est de savoir ce que les moyens moins chers de trouver le temps sont disponibles. En général, il n'y aura pas de bon moyen moins cher. Si vous êtes sur X86, vous pouvez demander à la CPU avec l'instruction RDTSC (et il y a probablement un analogue d'autres architectures de la CPU) - c'est une instruction de montage unique qui n'est pas privilégiée, vous pouvez donc le laisser tomber dans votre code n'importe où. Mais il y a beaucoup de pièges - RDTSC n'augmente pas toujours à un taux prévisible, surtout si la vitesse de la CPU change pour la gestion de l'alimentation, en fonction du modèle précis de la CPU que vous utilisez; Les valeurs peuvent ne pas être synchronisées sur plusieurs processeurs, etc. Le système d'exploitation garde une trace de tout cela et vous donnera la version conviviale et facile à utiliser des informations lorsque vous appelez GetTimeOdday ().
Temps d'appel (NULL) est pas un appel système, c'est VDSO.
sur Linux (pas les anciens), ce n'est pas un appel système, et c'est vraiment rapide, si rapide qui prend juste moins de 10 cycles. Mis en œuvre dans VDSO, qui est l'appel de l'espace utilisateur.