Trimming variable fat

[Rocker8956]

This is probably an amateur coder question but I am an amateur coder so…
I was looking through some of my recent code submissions and noticed I use int in places uint8 or uint16 would suffice. Would it be worth going through the code and trimming the fat on some of the variables?

Also, does a uint8 process faster and use less memory than a uint16?

Here is my list of variables I think could be trimmed (if you can think of more please let me know)

Reference Type Min Max
Level uint8 0 255
ZoneID uint16 0 65535
charID uint16 0 65535
accountID uint16 0 65535
spawnID uint32 0 4294967295

Regarding accountID and charID, I doubt a server should ever reach 65535 accounts/characters in its database. Am I wrong?

I am willing to look through the code and make the changes. Just want to be certain I am not wasting my time or messing something up.

[AndMetal]

Unless I'm missing something, using uint8 vs uint16 will use 50% less memory to store the number (1 byte vs 2 bytes). On a small scale, it's not really that big of a deal (1 megabyte is 1,048,576 bytes). However, in the long run, it's a good idea to use the smaller data types. When it comes to processing cycles, I have no idea what kind of impact that would have.

The big thing we need to keep in mind is expandability. That's why Y2K (http://en.wikipedia.org/wiki/Year_2000_problem) happened in the first place.

I think Level & ZoneID should be fine as 8/16 bit respectively, but if we made charID and accountID 16 bit, some of the higher population servers will run into issues before too long (if they wouldn't currently). I know on my server since I started it sometime in 2007, I have 2185 accounts with 4673 characters. At most, I think I've had 7 people on at once. Compare that to a server like PEQ, and you're talking about 50 times as many people on at peak times. That doesn't include people deleting characters (the database won't reuse those old character IDs). I would guess that would put total characters somewhere in the ballpark of 40,000 to 100,000.

I think, if it were possible, a 24 bit integer, similar to MEDIUMINT (http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html) in MySQL, might be a good compromise. However, I think it's better to just keep them as 32 bit integers.

I think a bigger optimization would be trimming down temporary data used in functions (for loops and such). I don't think the time investment would be worth the memory/performance increase, but it's still the "better" way to do it.

[cavedude]

Compare that to a server like PEQ, and you're talking about 50 times as many people on at peak times. That doesn't include people deleting characters (the database won't reuse those old character IDs). I would guess that would put total characters somewhere in the ballpark of 40,000 to 100,000.

Right on, 44,011 characters, 19,414 accounts.

[ChaosSlayer]

while we on the subject of too low caps, how about:

-increase stat/resist cap value on items above 127
-increase max lev cap value above 255
-increase player mana/hp cap value above 32k (this one becoming an issue on more than just a few servers allready)

[AndMetal]

while we on the subject of too low caps, how about:

-increase stat/resist cap value on items above 127
-increase max lev cap value above 255
-increase player mana/hp cap value above 32k (this one becoming an issue on more than just a few servers allready)

I think these start to tie into client limitations. Here is what the server utilizes:
zone/mob.h

sint16 AC;
sint32 HP;
sint32 HPRegen;
sint32 ManaRegen;
sint32 EnduranceRegen;
sint16 Mana;
sint32 Endurance;
sint16 ATK;
sint16 STR;
sint16 STA;
sint16 DEX;
sint16 AGI;
sint16 INT;
sint16 WIS;
sint16 CHA;
sint16 MR;
sint16 FR;
sint16 CR;
sint16 PR;
sint16 DR;

so they could theoretically go up to 32,767 for most stats, including mana (this could probably stand to be changed to 32-bit, seeing as how Client::CalcMaxMana returns it as such), & 2,147,483,647 for HP.

[spoon]

edit: brain fart