Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualThe King2

Posted 27 March 2013 - 01:42 PM

What does your profiler tell you?

Rather than simply guessing at what is slow, use a profiler will take measurements and pinpoint exactly what is slow.

 

Well my intention is not necessarly based on that I've run into some sort of performance issue, while I did profile (it showed me that GetModel(), GetEffect() and GetTexture() are by far the methods that take up the most time) its more like this: I've written this render system as quick and dirty as possible to get things to showing up, well aware that the code is anything then optimal. Based on the asumption that e.g. creating those matrices every frame is slower than storing it (while this is an assumption, isn't it a pretty accurate one? Since evading 5 possible matrix multiplications per frame per object should do at least something - it might not be the performance killer #1 in the app, but it's still going to be faster.. right?), I've asked this question. One might call me one premature optimisation, but isn't it pretty obvious in this case?

 

 

It looks like you are using lazy loading in your Search/Get functions, but for your entities, try to use a quicker algorithm for find() if you can, it's usually linear time in complexity. I used a binary search algorithm for named entities, at the expense of taking a slightly longer insertion time when ordering them alphabetically. Also, make sure to handle name clashes elegantly if you happen to try to create a new entity with the name of an existing one.

 

Hm, interesting thought, but are you sure we are talking about the same topic here? I wouldn't want to search my entities based on name. In this case e.g. I want every entity that has a position and a model component - no matter what the entity itself is. Wouldn't it be contraproductive if I had to search for entities based on names here? All my render system cares about is that it actually can render an entity (thus it has at least a position and a renderable)- I might add some more factors too once I get to implement more complex things... The actual implementation of "EntitiesWithComponents" doesn't even use find at all, it uses this:

 

template<typename C, typename... Components>
EntityManager::entityVector* EntityManager::EntitiesWithComponents(void)
{

    ComponentMask mask = componentMask<C, Components...>();
    entityVector* vMatchingEntities = new entityVector;
    for(entityVector::const_iterator ii = m_vEntities.cbegin(); ii != m_vEntities.cend(); ++ii)
    {
        if( (mask & (*ii)->GetMask()) == mask)
            vMatchingEntities->push_back(*ii);
    }
    return vMatchingEntities;
}

I store all my entities in a vector<>. Now I know this implementation is lacking, but because I might need to access an entity by any combination of components at any time - there is not much of a choice for optimisation, at least on that level. Like I suggested I might use a custom iterator to simply skip over all entities that doesn't match the wanted components, but other than that - I don't really know what else to optimize.

 

 

Also, are you reading the debug runtime messages and warnings for redundant state changes?

 

Yes, I do. Or say I tried, there is way to many of them. But again, those might actually reduce to a minimum once I actually implement a renderqueue, right now I don't see much point in reducing those. I quess my next goal should really be that render queue, but I somehow can't motivate myself to doing it :/


#3The King2

Posted 27 March 2013 - 01:42 PM

What does your profiler tell you?

Rather than simply guessing at what is slow, use a profiler will take measurements and pinpoint exactly what is slow.

 

Well my intention is not necessarly based on that I've run into some sort of performance issue, while I did profile (it showed me that GetModel(), GetEffect() and GetTexture() are by far the methods that take up the most time) its more like this: I've written this render system as quick and dirty as possible to get things to showing up, well aware that the code is anything then optimal. Based on the asumption that e.g. creating those matrices every frame is slower than storing it (while this is an assumption, isn't it a pretty accurate one? Since evading 5 possible matrix multiplications per frame per object should do at least something - it might not be the performance killer #1 in the app, but it's still going to be faster.. right?), I've asked this question. One might call me one premature optimisation, but isn't it pretty obvious in this case?

 

 

It looks like you are using lazy loading in your Search/Get functions, but for your entities, try to use a quicker algorithm for find() if you can, it's usually linear time in complexity. I used a binary search algorithm for named entities, at the expense of taking a slightly longer insertion time when ordering them alphabetically. Also, make sure to handle name clashes elegantly if you happen to try to create a new entity with the name of an existing one.

 

Hm, interesting thought, but are you sure we are talking about the same topic here? I wouldn't want to search my entities based on name. In this case e.g. I want every entity that has a position and a model component - no matter what the entity itself is. Wouldn't it be contraproductive if I had to search for entities based on names here? All my render system cares about is that it actually can render an entity (thus it has at least a position and a renderable)- I might add some more factors too once I get to implement more complex things... The actual implementation of "EntitiesWithComponents" doesn't even use find at all, it uses this:

 

template<typename C, typename... Components>
EntityManager::entityVector* EntityManager::EntitiesWithComponents(void)
{

    ComponentMask mask = componentMask<C, Components...>();
    entityVector* vMatchingEntities = new entityVector;
    for(entityVector::const_iterator ii = m_vEntities.cbegin(); ii != m_vEntities.cend(); ++ii)
    {
        if( (mask & (*ii)->GetMask()) == mask)
            vMatchingEntities->push_back(*ii);
    }
    return vMatchingEntities;
}

I store all my entities in a vector<>. Now I know this implementation is lacking, but because I might need to access an entity by any combination of components at any time - there is not much of a choice for optimisation, at least on that level. Like I suggested I might use a custom iterator to simply skip over all entities that doesn't match the wanted components, but other than that - I don't really know what else to optimize.

 

 

Also, are you reading the debug runtime messages and warnings for redundant state changes?

 

Yes, I do. Or say I tried, there is way to many of them. But again, those might actually reduce to a minimum once I actually implement a renderqueue, right now I don't see much point in reducing those. I quess my next goal should really be that render queue, but I somehow can't motivate myself to doing it :/


#2The King2

Posted 27 March 2013 - 01:42 PM

What does your profiler tell you?

Rather than simply guessing at what is slow, use a profiler will take measurements and pinpoint exactly what is slow.

 

Well my intention is not necessarly based on that I've run into some sort of performance issue, while I did profile (it showed me that GetModel(), GetEffect() and GetTexture() are by far the methods that take up the most time) its more like this: I've written this render system as quick and dirty as possible to get things to showing up, well aware that the code is anything then optimal. Based on the asumption that e.g. creating those matrices every frame is slower than storing it (while this is an assumption, isn't it a pretty accurate one? Since evading 5 possible matrix multiplications per frame per object should do at least something - it might not be the performance killer #1 in the app, but it's still going to be faster.. right?), I've asked this question. One might call me one premature optimisation, but isn't it pretty obvious in this case?

 

It looks like you are using lazy loading in your Search/Get functions, but for your entities, try to use a quicker algorithm for find() if you can, it's usually linear time in complexity. I used a binary search algorithm for named entities, at the expense of taking a slightly longer insertion time when ordering them alphabetically. Also, make sure to handle name clashes elegantly if you happen to try to create a new entity with the name of an existing one.

 

Hm, interesting thought, but are you sure we are talking about the same topic here? I wouldn't want to search my entities based on name. In this case e.g. I want every entity that has a position and a model component - no matter what the entity itself is. Wouldn't it be contraproductive if I had to search for entities based on names here? All my render system cares about is that it actually can render an entity (thus it has at least a position and a renderable)- I might add some more factors too once I get to implement more complex things... The actual implementation of "EntitiesWithComponents" doesn't even use find at all, it uses this:

 

template<typename C, typename... Components>
EntityManager::entityVector* EntityManager::EntitiesWithComponents(void)
{
    //todo: performance optimize
    ComponentMask mask = componentMask<C, Components...>();
    entityVector* vMatchingEntities = new entityVector;
    for(entityVector::const_iterator ii = m_vEntities.cbegin(); ii != m_vEntities.cend(); ++ii)
    {
        if( (mask & (*ii)->GetMask()) == mask)
            vMatchingEntities->push_back(*ii);
    }
    return vMatchingEntities;
}

I store all my entities in a vector<>. Now I know this implementation is lacking, but because I might need to access an entity by any combination of components at any time - there is not much of a choice for optimisation, at least on that level. Like I suggested I might use a custom iterator to simply skip over all entities that doesn't match the wanted components, but other than that - I don't really know what else to optimize.

 

Also, are you reading the debug runtime messages and warnings for redundant state changes?

 

Yes, I do. Or say I tried, there is way to many of them. But again, those might actually reduce to a minimum once I actually implement a renderqueue, right now I don't see much point in reducing those. I quess my next goal should really be that render queue, but I somehow can't motivate myself to doing it :/


#1The King2

Posted 27 March 2013 - 01:29 PM

What does your profiler tell you?

Rather than simply guessing at what is slow, use a profiler will take measurements and pinpoint exactly what is slow.

 

Well my intention is not necessarly based on that I've run into some sort of performance issue, while I did profile (it showed me that GetModel(), GetEffect() and GetTexture() are by far the methods that take up the most time) its more like this: I've written this render system as quick and dirty as possible to get things to showing up, well aware that the code is anything then optimal. Based on the asumption that e.g. creating those matrices every frame is slower than storing it (while this is an assumption, isn't it a pretty accurate one? Since evading 5 possible matrix multiplications per frame per object should do at least something - it might not be the performance killer #1 in the app, but it's still going to be faster.. right?), I've asked this question. One might call me one premature optimisation, but isn't it pretty obvious in this case?


PARTNERS