Benchmarking avec googletest?

Contexte (passez à la question ci-dessous si cela ne vous intéresse pas)

J’ai un simulateur qui traverse trois états:

1. Démarrage à un seul thread (I / O ok)
2. Etape de simulation liée à la CPU multi-thread en mémoire (I / O pas ok)
3. Post-single threaded post-simulation, post-jointure (I / O ok)

Que diable! Lors des tests standard, l’utilisation du processeur a chuté de 100% à 20% , et la durée totale d’utilisation a été environ 30 fois plus longue que la normale (130 secondes contre 4,2 secondes).

Lorsque Callgrind ne révéla plus rien de suspect, ma tête bourdonna alors que j’étais sur le sharepoint revenir au dernier commit, perdant ainsi toutes les corrections de bugs.

Découragé, je suis entré dans la salle des serveurs pendant une course et j’ai remarqué des sons de grincement désagréables, qui auraient été causés ultérieurement par des écritures sur des sockets Mysql dans / proc / PID / fd !!! Il s’est avéré que le code Mysql, plusieurs couches profondes dans l’étape 2., posait problème.

• boost :: delay_timer peut échouer lorsque l’horloge système est modifiée
• La période Android du chrono NDK n’est pas correcte (std :: chrono :: high_resolution_clock)
• Pourquoi utiliser boost :: tuple .get ne fonctionne-t-il pas dans les fonctions de gabarit dans gcc?
• Existe-t-il une garantie de vidage automatique de stdout avant la sortie? Comment ça marche?
• C ++ iterator de const_iterator

Leçons apsockets

1. Les E / S accidentelles peuvent être mortelles pour une application en temps réel
2. Les tests unitaires ne suffisent pas: j’ai aussi besoin d’parsings comparatives

Correctif J’introduirai IOSentinels et asserts () de stockage local de thread sur ReadAllowed () et WriteAllowed () afin de garantir que les threads de l’étape 2 ne feront jamais d’IO.

Question

Quelqu’un at-il un peu de chance avec l’attachement / l’écriture d’un framework de benchmarking avec googletest?

Malheureusement, tous mes googlets ont passé cette fois. Si je m’étais éloigné un peu et que je revenais sans remarquer le temps d’exécution, cela aurait été un commit désastreux, et peut-être beaucoup plus difficile à réparer.

Je voudrais que googletest échoue si une exécution prend> 2 ou 3 fois la dernière exécution: cette dernière partie est délicate car, dans le cas d’une exécution très rapide, l’état du système peut provoquer une perte de temps deux fois plus longue, mais tout de même. Mais pour une longue simulation / simulation, je ne m’attends pas à ce que les durées d’exécution changent considérablement (> 50% serait inhabituel).

Je suis ouvert aux suggestions ici, mais il serait bien d’avoir une vérification nécessitant peu d’entretien qui fonctionnerait avec des tests automatisés, de sorte que le fait que le système devienne soudainement lent, même si toutes les sorties semblent correctes, sera évident.

• Entrelacement efficace des bits
• Un bogue de variables basées sur un modèle avec Lambdas dans Visual Studio?
• Comprendre le résultat de la compilation pour std :: isnan
• Comment puis-je convertir ou convertir une reliure renforcée au pointeur de fonction C?
• donnez la signification de / * pour dereference et division pas pour commenter en ajoutant un caractère spécial

 const clock_t t0 = clock(); // or gettimeofday or whatever int res = yourFunction(); const clock_t t1 = clock(); const double elapsedSec = (t1 - t0) / (double)CLOCKS_PER_SEC; EXPECT_EQ(EXPECTED, res); EXPECT_GT(10.0, elapsedSec); 

 double prev = -1; { ifstream ifs("/var/tmp/time_record.txt"); ifs >> prev; } if (prev < 0) prev = DEFAULT_VALUE; // ... EXPECT_GT(2 * prev, elapsedSec); { ofstream ofs("/var/tmp/time_record.txt"); ofs << elapsedSec << endl; }