0

I am currently benchmarking a program on a Linux system with Valgrind. I have this strange cache miss with the getter method const int GetID() const, but I can't really explain where it came from. Does anyone have any idea what's causing this problem? I thought it might be caused by the constant keyword at the end, but it hasn't changed.

The cache miss occurs in the L1 during the read operation. I have added a screenshot below the code snippet.

class GameObject
{
friend class GameManager;

private:
    int id; 

    GameObject();
    static int CreateID() { return /* do some id stuff in here */}
    ...

public:
    ~GameObject();
    const int GetID() const { return id; }
    ...
};

KCachegrind Screenshot:

enter image description here

UPDATE:

These are methods of the GameManager class that call the const int GetID() const method. It is called when a GameObject must be destroyed or returned to a specific point. The GameManager contains a vector of all GameObjects, they are created when the application starts, after which the vector does not change at all. After they are created, the attached components call the GameObject* GetGameObject(int const _gameObjectId) method once to retrieve all required components. So I guess the GameObjects should already be in the cache or did I miss a point? Maybe the call is so strong that it creates more cache misses at the beginning of the program than the rest of the application at runtime?

void GameManager::DestroyGameObject(const int _id)
{
    for (auto it = gameObjects.begin(); it != gameObjects.end(); it++)
    {
        if (it->GetID() == _id)
        {
            gameObjects.erase(it);
            return;
        }
    }
}

GameObject* GameManager::GetGameObject(const int _gameObjectId)
{
    for (int i = 0; i < gameObjects.size(); i++)
    {
        if (gameObjects[i].GetID() == _gameObjectId)
        {
            return &gameObjects[i];
        }
    }
    return nullptr;
}
  • I think we need more code than this to understand what's going on, can it be your instance ain't in the cache and the getter is the first user of that instance? – JVApen May 30 '20 at 08:15
  • @JVApen, thank you very much for the answer! I have updated the article, I hope this is clearer now. Let me know if this is still not enough information. – RunningFlip May 30 '20 at 09:49

0 Answers0