Je développe une application en utilisant OpenSceneGraph et je rencontre un comportement étrange dans une instruction if. Je ne suis pas sûr que ce soit spécifique à l'API, car cela n'a aucun sens pour moi.Comportement étrange utilisant l'instruction if
Le code:
if (!fileAddList_.empty())
{
sg::FileStampThread::instance()->addFiles(fileAddList_);
fileAddList_.clear();
}
Où:
fileAddList_: un vecteur statique d'objets personnalisés utilisés pour maintenir les noms de fichiers
FileStampThread: une instance d'un objet OpenThreads
addfiles(): une méthode dans le thread qui enregistre la liste des fichiers objets qui lui sont passés
Le code ci-dessus met en œuvre hotloading dans ma demande. L'instance FileStampThread s'exécute en continu, en vérifiant les horodatages des noms de fichiers qui lui sont transmis. Une fois le tampon modifié, le nom de fichier est enregistré dans une autre liste et renvoyé pour rechargement. Ce qui est étrange, c'est que la traversée de mise à jour du graphe de scène (quand ce code est exécuté) ralentit considérablement quand j'active cette section de code, même s'il n'y a aucun fichier à ajouter (même si fileAddList_ est vide). Le temps de parcours de mise à jour augmente par conséquent d'un ordre de grandeur. Cependant, si je commente l'appel à sg :: FileStampThread :: addFiles, le ralentissement disparaît. Pourtant, j'ai piégé l'appel en mode débogage et il ne sera jamais exécuté. Donc, je suis perplexe: pourquoi une ligne de code à l'intérieur d'un conditionnel affecte-t-elle la vitesse d'exécution de mon programme quand le test conditionnel échoue et, selon toute apparence, il n'est jamais exécuté? En guise de note secondaire, je soupçonnais que cela pouvait avoir quelque chose à voir avec la déclaration de la variable comme étant statique, alors j'ai essayé de la déclarer global (en utilisant extern) à la place, dans le même but.
Une édition pour aborder quelques-uns des commentaires ci-dessous:
Le fil est une instance d'un objet OpenThreads. Pas de MS spécifique choses, ici. L'instance est statique.
addfiles() ne sont pas basés sur des modèles
Je l'ai testé la boucle avec le code en elle. J'ai commenté les lignes alternativement. Je suis absolument positif inclusion de l'appel addFiles() est le coupable.
Déboguer vs Release n'est pas différent, en poussant le code dans une fonction séparée rien changé, malheureusement.
- OSG est à haute performance et le commentaire sur la mauvaise interprétation pourrait être droit. Recherche à venir ...
Code de la classe FileStampThread:
void sg::FileStampThread::addFiles(sg::AssetFileList& files)
{
OpenThreads::ScopedLock<OpenThreads::Mutex> lock(contentMutex_);
for (sg::AssetFileList::iterator it = files.begin(); it != files.end(); ++it)
{
if (boost::filesystem::exists((*it).getPath()))
fileList_.push_back((*it));
}
};
FileStampThread est-il dans un département COM? Et quel type de sécurité de fil est utilisé dans cette classe (pour en faire un singleton sûr)? –
Il est assez difficile à voir sans un accès réel au problème et au code. Une réponse simple à * pourquoi cela affecterait la vitesse * pourrait être une mauvaise prédiction de branche, mais vous ne le remarquerez que si cela a été exécuté dans une boucle serrée. Si cela se trouve dans un chemin de code à haute performance, pensez à ajouter des indications pour le compilateur. –
Eh bien, en théorie, si addFiles est une méthode basée sur un modèle, le fait que vous l'appeliez quelque part provoquera son instanciation. Vous pourriez faire d'autres instanciations de template dans addFiles qui ont des effets secondaires globaux. C'est un long coup cependant. – enobayram