[TheDS1337]

Hey guys, I've been hearing a lot that I should declare variable outside the loop for example:

PHP Code:

    int value;

    for (int iterator = 99999; iterator > 0; iterator--)
    {
         value = 1000;

         /* Do something */    
    } 


Instead of doing:

PHP Code:

    for (int iterator = 99999; iterator > 0; iterator--)
    {
         int value = 1000;

         /* Do something */    
    } 


Well in C++ some said that C++ compilers are smart enough to optimize it for you, but does it happen with sourcemod compiler ?

[thecount]

Good practice to assume it doesn't.

[Impact123]

You could compile it and then run it through the lysis online decompiler. Spcomp also has an -a flag that you might be interested in.

[TheDS1337]

Nice idea, I'll try that tomorrow, Good night for now.

[h3bus]

AFAIK, the variable is "allocated" at compile time (on stack or heap), thus both code should give the same binary.

[klippy]

Originally Posted by h3bus AFAIK, the variable is "allocated" at compile time (on stack or heap), thus both code should give the same binary.

Global/static variables are indeed allocated at compile time, but local variables aren't. Stack allocation isn't really allocation actually (the plugin won't take more memory), only the stack pointer is moved, and that stack pointer moving is an additional instruction. Memory isn't the concern here, it's the execution time.

[TheDS1337]

Declaring the variable outside the "for" block:

PHP Code:

public void:OnPluginStart()
{
    new value;
    new i;
    while (i < 100)
    {
        value = 1000000000;
        i++;
    }
    return void:0;
} 


Inside it:

PHP Code:

public void:OnPluginStart()
{
    new i;
    while (i < 100)
    {
        i++;
    }
    return void:0;
} 


[ddhoward]

It doesn't look like the variable even made it into the code in the second snippet at all...

[h3bus]

Originally Posted by KliPPy Global/static variables are indeed allocated at compile time, but local variables aren't. Stack allocation isn't really allocation actually (the plugin won't take more memory), only the stack pointer is moved, and that stack pointer moving is an additional instruction. Memory isn't the concern here, it's the execution time.

That's why I put the quote around "allocated". My point that there is little chance that stack pointer is pushed up and down at each loop as wherever that variable is in the code, its displacement relative to stack/heap pointer is most likely static after compile time.

[Potato Uno]

They probably do optimize that (can't be bothered to check the C++ source) since the JIT does a more or less 1-to-1 mapping of SM bytecode to assembly/machine code.

It's better to assume that the compiler is dumb and does a simple 1-to-1 mapping of pawn to bytecode with no optimizations in place. Having said that, you should only declare things outside of loop if the loop is to be ran an insane number of times (insane being relative, of course). If the loop is only ran several times (on the order of magnitude of 100), depending on complexity it's sometimes better to just leave the declaration in the loop. Otherwise you may introduce subtle bugs in your plugin just for a 0.0000001% speedup or something (premature optimization trap).

Realistically speaking though, integer declarations are pretty much negligible. It's only sizable string or array declarations that you should be looking at moving outside of loops or to global scope.