AlliedModders

AlliedModders (https://forums.alliedmods.net/index.php)
-   Scripting Help (https://forums.alliedmods.net/forumdisplay.php?f=11)
-   -   Optimizations questions (https://forums.alliedmods.net/showthread.php?t=281727)

Syturi0 04-18-2016 22:20

Optimizations questions
 
PHP Code:

return PLUGIN_HANDLED 

Should i always return PLUGIN_HANDLED at the end of code? Does it matter? Does it affect performance?
Example:
PHP Code:

public MenuTest(id)
{
    new 
Menu menu_create(sMenu"MenuTest_Handler")

    
menu_additem(Menu"test 1"""0)
    
menu_additem(Menu"teste 2"""0)

    
menu_setprop(MenuMPROP_EXITMEXIT_NEVER)
    
menu_setprop(MenuMPROP_PERPAGE6)

    
menu_display(idMenu0)
    return 
PLUGING_HANDLED




==========================

Is it better to have all plugins seperated, or have a HUGE with all of them inside a single one?
Does it affect performance?

==========================

When doing loops:
PHP Code:

    new iPlayers[32], iNum
    get_players
(iPlayersiNum"ch")

    for(new 
0iNumi++) 

Should i use "new i" inside "for()", or outside?
Like this:
PHP Code:

    new iPlayers[32], iNumi
    get_players
(iPlayersiNum"ch")

    for(
0iNumi++) 


fysiks 04-18-2016 22:45

Re: Optimizations questions
 
The return value will depend on what you are doing. You should return the value that makes the most sense and does what you want it to do for that function. Also, PLUGIN_* return values only have meaning in certain contexts. I remember that there was a good post about the return values around here somewhere. EDIT: Here is one such thread.

There is no reason to merge plugins that do not need to merge functionality. Any efficiency gain by merging plugins for no reason will not be appreciable and will make things harder in the long run. Generally, it is good practice to separate functionality into separate plugins (this is called modularity and is an important concept in software engineering).

I don't believe there is any appreciable difference with creating the counting variable in the for loop construct. The first of the three arguments is only called once. The second and third arguments of the for() are both called on every iteration. That is why you will see people remove functions from the second and third arguments (e.g. "i < get_maxplayers()" as the conditional should be avoided).

Syturi0 04-18-2016 22:58

Re: Optimizations questions
 
Quote:

Originally Posted by fysiks (Post 2412219)
The return value will depend on what you are doing. You should return the value that makes the most sense and does what you want it to do for that function. Also, PLUGIN_* return values only have meaning in certain contexts. I remember that there was a good post about the return values around here somewhere.

There is no reason to merge plugins that do not need to merge functionality. Any efficiency gain by merging plugins for no reason will not be appreciable and will make things harder in the long run. Generally, it is good practice to separate functionality into separate plugins (this is called modularity and is an important concept in software engineering).

I don't believe there is any appreciable difference with creating the counting variable in the for loop construct. The first of the three arguments is only called once. The second and third arguments of the for() are both called on every iteration. That is why you will see people remove functions from the second and third arguments (e.g. "i < get_maxplayers()" as the conditional should be avoided).

Thank you alot!


I made this because I saw some of plugins using "return PLUGIN_HANDLED" all the time for no reason, thats why i got confuse.
Same thing with loop, i saw a guy somewhere saying that "new i = 0" is called on every iteration, and it must be used outside for(), but i was not sure.

fysiks 04-18-2016 22:59

Re: Optimizations questions
 
Quote:

Originally Posted by Syturi0 (Post 2412223)
I made this because I saw some of plugins using "return PLUGIN_HANDLED" all the time for no reason, thats why i got confuse.

It depends on the use case.


Quote:

Originally Posted by Syturi0 (Post 2412223)
Same thing with loop, i saw a guy somewhere saying that "new i = 0" is called on every iteration, and it must be used outside for(), but i was not sure.

I could be wrong. Someone who knows more about Pawn would probably need to confirm or deny my statements.

Syturi0 04-18-2016 23:09

Re: Optimizations questions
 
Btw, why i see alot of plugins using:
PHP Code:

#define MAX_PLAYERS 32
new test[MAX_PLAYERS 1

Why not just type [33] instead? '-' ...

fysiks 04-18-2016 23:15

Re: Optimizations questions
 
It makes it easy to change the max number of players without changing any actual code. Also, it's self documenting code, it specifies that 32 of the 33 cells are for player entities. The extra 1 cell is only there to make it easier to index arrays by entity index (which is 1 based in the context of players).

klippy 04-19-2016 00:54

Re: Optimizations questions
 
Well, if "new i = 0" was called each iteration you would be stuck in an infinite loop as the value of "i" variable would never be anything other than 0.
So, logically, it is called only once before iterating starts.

fysiks 04-19-2016 09:13

Re: Optimizations questions
 
Quote:

Originally Posted by KliPPy (Post 2412240)
Well, if "new i = 0" was called each iteration you would be stuck in an infinite loop as the value of "i" variable would never be anything other than 0.
So, logically, it is called only once before iterating starts.

Yep, that's the logic that I used.

claudiuhks 04-20-2016 05:00

Re: Optimizations questions
 
Quote:

Originally Posted by Syturi0 (Post 2412215)
Should i always return PLUGIN_HANDLED at the end of code? Does it matter? Does it affect performance?

If no return word is found, return 0 (Plug-In Continue) is taken by default.
All forwards return int. `return;' is probably taken as `return 0;'.

Quote:

Originally Posted by Syturi0 (Post 2412215)
Is it better to have all plugins seperated, or have a HUGE with all of them inside a single one?
Does it affect performance?

It depends. You can run 8192 plug-ins if all of them only use Plug-In Init forward and Register Plug-In function.

It may affect the performance when such situation (see below) is met.

PHP Code:

// a.amxx

public OnPlayerPreThink(Id)
{
  if (!
is_user_alive(Id)) { }
  else
  {
    if (
pev(Idpev_button) & IN_DUCK) { }
  }
}

// b.amxx

public OnPlayerPreThink(Id)
{
  if (!
is_user_alive(Id)) { }
  else
  {
    if (
pev(Idpev_button) & IN_ATTACK) { }
  }


Why executing is_user_alive() twice? Better merge a.amxx and b.amxx resulting in less function calls (is_user_alive).

PHP Code:

// ab.amxx

public OnPlayerPreThink(Id)
{
  static 
Button;

  if (!
is_user_alive(Id)) { }
  else
  {
    
Button pev(Idpev_button);

    if (
Button 0)
    {
      if (
Button IN_ATTACK) { }
      
/* else   (for async.) */ if (Button IN_DUCK) { }
    }
  }



Syturi0 04-20-2016 12:24

Re: Optimizations questions
 
Quote:

Originally Posted by claudiuhks (Post 2412565)
If no return word is found, return 0 (Plug-In Continue) is taken by default.
All forwards return int. `return;' is probably taken as `return 0;'.



It depends. You can run 8192 plug-ins if all of them only use Plug-In Init forward and Register Plug-In function.

It may affect the performance when such situation (see below) is met.

PHP Code:

// a.amxx

public OnPlayerPreThink(Id)
{
  if (!
is_user_alive(Id)) { }
  else
  {
    if (
pev(Idpev_button) & IN_DUCK) { }
  }
}

// b.amxx

public OnPlayerPreThink(Id)
{
  if (!
is_user_alive(Id)) { }
  else
  {
    if (
pev(Idpev_button) & IN_ATTACK) { }
  }


Why executing is_user_alive() twice? Better merge a.amxx and b.amxx resulting in less function calls (is_user_alive).

PHP Code:

// ab.amxx

public OnPlayerPreThink(Id)
{
  static 
Button;

  if (!
is_user_alive(Id)) { }
  else
  {
    
Button pev(Idpev_button);

    if (
Button 0)
    {
      if (
Button IN_ATTACK) { }
      
/* else   (for async.) */ if (Button IN_DUCK) { }
    }
  }



Thank you.


All times are GMT -4. The time now is 18:38.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.