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 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 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]

Originally Posted by AndMetal

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]

Originally Posted by 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)

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