[Plugin] GVar Plugin - Printable Version

[Plugin] GVar Plugin - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP Scripting and Plugins (https://sampforum.blast.hk/forumdisplay.php?fid=8)
+--- Forum: Plugin Development (https://sampforum.blast.hk/forumdisplay.php?fid=18)
+--- Thread: [Plugin] GVar Plugin (/showthread.php?tid=151076)

Pages: 1 2 3 4 5 6

Re: [REL] GVar Plugin v1.0 - nemesis- - 30.05.2010

Quote:

Originally Posted by D0erf|er

Quote:

Originally Posted by nemesis99

Quote:

Originally Posted by $ЂЯĢ

@nemesis99, will you be ever looping 100'000 times over something? Probably no. Looping through 500 players would still take only 0.51ms (0.00051s), and that's like nothing.

How about not looping at all? You didn't understand what I said.

You've also a lot to learn about efficiency. Read this for starters: Algorithmic Efficiency. While this plugin does have potential gains in the way of memory efficiency, SA:MP servers have bigger worries, namely, CPU utilization.

The only thing you shouldn't do then is using it in onplayerupdate.

It is slower, yes, but it is not that slow that it is not worth using it.

and the good thing is that you can set a gvar in your gamemode and access it in all other scripts.

It isn't worth using if the pawn native alternatives are faster albeit take a little extra brain power to code with. Pvars make life easier for the novice coder. The experienced one will see its' downsides and revert to a more efficient solution, even if slightly more complex to code. Like I said, CPU utilization is a SA:MP coders enemy, not memory utilization. I have more memory issues to worry about with Apache/SMF/MySQL than I do SA:MP.

Re: [REL] GVar Plugin v1.0 - Sergei - 30.05.2010

Now you are blowing it up way too much. Memory is bigger problem in SA:MP than CPU (http://forum.sa-mp.com/index.php?top...0.0#post_trade). PVars just give us ability to use dynamic memory which pawn don't have and it limits us very much because of that.

If you have so many problems with simple thing like SMF then I suggest you to get yourself some hardware upgrades, or even better separate server for each of those major services (SA:MP, web, MySQL).

Re: [REL] GVar Plugin v1.0 - nemesis- - 30.05.2010

Quote:

Originally Posted by $ЂЯĢ

Now you are blowing it up way too much. Memory is bigger problem in SA:MP than CPU (http://forum.sa-mp.com/index.php?top...0.0#post_trade). PVars just give us ability to use dynamic memory which pawn don't have and it limits us very much because of that.

If you have so many problems with simple thing like SMF then I suggest you to get yourself some hardware upgrades, or even better separate server for each of those major services (SA:MP, web, MySQL).

You have even bigger problems - the ability to comprehend. I'm out of this thread. You still have no clue what I'm talking about. You've evaded every question and are even ignoring your own proof. You didn't even answer my original post. Have you ever run a server rather than troll these forums?

Incog: Your other plugins (Streamer + IRC) are god sends and some incredibly important and helpful tools. I can't thank you enough for these contributions to the SA:MP community. This one I'm sad to say hooks off of a function (Pvars) that in my opinion added no value to SA:MP. They will help novice coders but experienced coders (with Serg's own benchmarking as support) will avoid it.

Re: [REL] GVar Plugin v1.0 - Sergei - 30.05.2010

I don't see any question mark in any of your posts in this topic, so cya o/. And if you can't see more pros than cons of P/G-vars then it's not my problem, just don't say you can replace it completly with your "complex" scripting.

Re: [REL] GVar Plugin v1.0 - nemesis- - 30.05.2010

Have you actually read the pawn language manual and even LOOKED at the get/set/existproperty functions? If so, you might not be so quick to open that trap and contradict me, troll.

Re: [REL] GVar Plugin v1.0 - Sergei - 30.05.2010

Have you ever asked yourself why you are the only one using property functions?

Re: [REL] GVar Plugin v1.0 - Calgon - 30.05.2010

Quote:

Originally Posted by nemesis99

Have you actually read the pawn language manual and even LOOKED at the get/set/existproperty functions? If so, you might not be so quick to open that trap and contradict me, troll.

I thought you were going to stop replying.

Re: [REL] GVar Plugin v1.0 - nemesis- - 30.05.2010

Quote:

Originally Posted by $ЂЯĢ

Have you ever asked yourself why you are the only one using property functions?

You still have no clue what I'm talking about. Begone incompetent troll.

Re: [REL] GVar Plugin v1.0 - Kyosaur - 30.05.2010

Quote:

Originally Posted by $ЂЯĢ

Have you ever asked yourself why you are the only one using property functions?

Dont assume just because YOU dont use something, no one else does. I use these functions as well.

Since you seem to be the expert here, please inform us all on whats wrong with the property functions?

Re: [REL] GVar Plugin v1.0 - Sergei - 30.05.2010

Anyone said that anything is wrong with them?

Quote:

Originally Posted by nemesis99

You still have no clue what I'm talking about. Begone incompetent troll.

Your level or maturity is falling proportionally with anger?

Re: [REL] GVar Plugin v1.0 - pyrodave - 30.05.2010

Quote:

Originally Posted by $ЂЯĢ

Anyone said that anything is wrong with them?

Quote:

Originally Posted by nemesis99

You still have no clue what I'm talking about. Begone incompetent troll.

Your level or maturity is falling proportionally with anger?

What the?! That makes so sense what-so-ever.

The property functions are native to pawn, and can cross through to filterscripts and the GM, which is exactly what p/g vars can do also. They're also dynamic in the sense they can be created and destroyed. Ok a little more work has to go into using and understanding them, but why not use something which is native?

Re: [REL] GVar Plugin v1.0 - Grim_ - 31.05.2010

Quote:

Originally Posted by DavidC

Quote:

Originally Posted by $ЂЯĢ

Anyone said that anything is wrong with them?

Quote:

Originally Posted by nemesis99

You still have no clue what I'm talking about. Begone incompetent troll.

Your level or maturity is falling proportionally with anger?

What the?! That makes so sense what-so-ever.

Yes it does..

Re: [REL] GVar Plugin v1.1 - Incognito - 31.05.2010

The GVar plugin is a wrapper around several hash tables as of the latest version. Hash tables have an amortized constant time complexity. I haven't done a detailed analysis on properties, so I can't say exactly what the complexity is for them, but their runtime does seem to increase almost linearly as more elements are added. Hash tables can also be described as having an O(1) complexity on average, which basically just means that the number of elements in a hash table has no bearing on its runtime under normal conditions. This is definitely not the case for properties. Below are some tests to prove it.

This code allocates 100,000 unique strings to be used as keys:

pawn Код:

new names[100000][16];
for (new i = 0; i < 100000; i++)
{
    format(names[i], sizeof(names[]), "name_%d", i);
}

GetTickCount will be used to calculate the time that has elapsed. It should be noted that because this native does not provide access to a high resolution timer, the results listed here could possibly be off by several milliseconds. However, the data should at least be accurate enough make a few simple comparisons.

Tests for SetGVarInt and GetGVarInt:

pawn Код:

new time = GetTickCount();
for (new i = 0; i < 100000; i++)
{
    SetGVarInt(names[i], i);
}
printf("Time #1: %d", GetTickCount() - time);

time = GetTickCount();
for (new i = 0; i < 100000; i++)
{
    GetGVarInt(names[i]);
}
printf("Time #2: %d", GetTickCount() - time);

The results:

Код:

[19:07:15] Time #1: 166
[19:07:15] Time #2: 52

The script took 166 milliseconds to allocate 100,000 elements and only 52 milliseconds to retrieve them.

Tests for setproperty and getproperty:

pawn Код:

new time = GetTickCount();
for (new i = 0; i < 100000; i++)
{
    setproperty(0, names[i], i);
}
printf("Time #1: %d", GetTickCount() - time);
    
time = GetTickCount();
for (new i = 0; i < 100000; i++)
{
    getproperty(0, names[i]);
}
printf("Time #2: %d", GetTickCount() - time);

The results:

Код:

[19:29:28] Time #1: 200739
[19:32:43] Time #2: 195040

Allocation of 100,000 elements with properties, on the other hand, took 200,739 milliseconds, and retrieval took 195,040 milliseconds—both well over 3 minutes. That's several orders of magnitude slower than GVars!

PVars aren't quite as bad, but they are limited to 800 elements per player. In order to make a proper comparison, the loops must be much smaller.

Tests for SetGVarInt and GetGVarInt (800 elements):

pawn Код:

new time = GetTickCount();
for (new i = 0; i < 800; i++)
{
    SetGVarInt(names[i], i);
}
printf("Time #1: %d", GetTickCount() - time);

time = GetTickCount();
for (new i = 0; i < 800; i++)
{
    GetGVarInt(names[i]);
}
printf("Time #2: %d", GetTickCount() - time);

The results:

Код:

[19:14:15] Time #1: 1
[19:14:15] Time #2: 1

Tests for SetPVarInt and GetPVarInt (800 elements):

pawn Код:

new time = GetTickCount();
for (new i = 0; i < 800; i++)
{
    SetPVarInt(playerid, names[i], i);
}
printf("Time #1: %d", GetTickCount() - time);

time = GetTickCount();
for (new i = 0; i < 800; i++)
{
    GetPVarInt(playerid, names[i]);
}
printf("Time #2: %d", GetTickCount() - time);

The results:

Код:

[19:14:30] Time #1: 4
[19:14:30] Time #2: 3

GVars are still slightly faster, but not by much. Properties and PVars might appear to be faster in a few specific cases, but PVars are limited in size and properties quickly become unmanageable as they increase in size. GVars have no imposed limits on storage capacity, and they also have an amortized constant time complexity. There are a few things to consider, however:

Long GVar names can increase runtime, so keep them short.
GetGVarsUpperIndex and GetGVarNameAtIndex both actually have a linear time complexity due to their different methods of implementation, so use them sparingly.

Edit: I have modified this post for clarity.

Re: [REL] GVar Plugin v1.1 - Grim_ - 31.05.2010

Outstanding work Incognito

You are the next ****** in my eyes :P

Re: [REL] GVar Plugin v1.1 - Sergei - 31.05.2010

Thank you for the update!

Re: [REL] GVar Plugin v1.1 - Rac3r - 31.05.2010

Thanks for the time analysis, cleared up a few things for me.

Nice plugin, really useful.

Re: [REL] GVar Plugin v1.2 - nemesis- - 20.06.2010

Quote:

Originally Posted by kingdutch

Quote:

Originally Posted by nemesis99

Quote:

Originally Posted by kingdutch

I was going to ask why you don't extend your GVar to also replace PVar as GVar is faster when I realised your GVar and PVar comparisons are actually flawed in that the PVar functions have another piece of data to work with when storing and retrieving data.

He can't. GVar is an extension of PVar.

GVar is actually a plugin which has nothing to do with PVar system (In terms of working, in terms of functionality they're very similar).

Re-read Incognito's initial post. He says it is an extension off of the PVar system.

Re: [REL] GVar Plugin v1.2 - yezizhu - 21.07.2010

Why sa-mp team do not mention PVar only suport 800 elements per player Update page?
amount 800 is still less, as I think.

If GVar is faster than PVar, how about use GVar instead of PVar system?

Like

pawn Код:

stock GetPVarIntEx(playerid,varname[]){
    return GetGVarInt(varname,1+playerid);
}
#define GetPVarInt(%1) GetPVarIntEx(%1)

Re: [REL] GVar Plugin v1.2 - Sergei - 21.07.2010

You ever needed more than 800 PVars? I think you shoudl start using DeletePVar if so.

Re: [REL] GVar Plugin v1.2 - yezizhu - 21.07.2010

Quote:

Originally Posted by Sergei

You ever needed more than 800 PVars? I think you shoudl start using DeletePVar if so.

Yep over 800 it's possible.
Some players have been trying to make a race which has more than 800 cp(they like what they do).

Yes I can split checkpoint data for loading dynamically, but isn't it more inconvenience than using pawn code?(Think I'm a lazy scripter xD)