function execution time

if a function is taking longer to execute every time it is called, what could that imply?

That's it's unpure and you're modifying some state that's hidden to the user. Unless there's input, in which the time taken might have something to do with increasing or decreasing input.

>>1
the function is working with a larger amount of data or you are using a shitty toy language like JS

memory leakage

alright I'm not getting anywhere. Heres the offending code, for some reason when it hits the return it takes about twice as long as the previous time to execute. I don't think it is a memory leak as this code and the function that calls it aren't concerned with memory allocation (but what do I know)

std::vector<std::vector<Segment> > Environment::_AIScopeSubArray(int yPos, int xPos, int AIScope)
{
    std::vector<std::vector<Segment> > subScope;
    int scopeRad = AIScope/2;

    subScope.resize(AIScope);
    for(int idx = 0; idx < AIScope; idx++)
        subScope[idx].resize(AIScope);

    for(int idx = 0; idx < AIScope; idx++)
        for(int jdx = 0; jdx < AIScope; jdx++)
        {
            if((idx+(yPos-scopeRad) >= 0) && (idx+(yPos-scopeRad) < GRIDSIZE) && (jdx+(xPos-scopeRad) >= 0) && (jdx+(xPos-scopeRad) < GRIDSIZE))
            {
                subScope[idx][jdx] = grid_[idx+(yPos-scopeRad)][jdx+(xPos-scopeRad)];
            }
            else
            {
                subScope[idx][jdx].setOOB(true);
            }
        }
        return subScope;
}

This is supposed to return a small portion of a larger grid, to act as a field of vision for some monsters

>>5
this code just gave me eye cancer

anyways returning a vector composed of vectors of special type Segment is retarded and it is time costly

>>6
I couldn't think of a better way to do it

is there anything that immediately stands out apart from bad coding?

>>7
An incremental improvement would be to make one giant vector<Segment> and index it as [AIScope * i + j] instead of [i][j].

>>8

thanks bro, I would have never thought of doing it like that

>>9
That probably won't actually solve the problem but it will make parts of it somewhat less hairy to debug