EQEmulator Forums - Trimming variable fat

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Feature Requests (https://www.eqemulator.org/forums/forumdisplay.php?f=612)

- - Trimming variable fat (https://www.eqemulator.org/forums/showthread.php?t=26478)

Trimming variable fat

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)

Code:

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.

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.

Quote:

Originally Posted by AndMetal (Post 158099)

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.

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)

Quote:

Originally Posted by ChaosSlayer (Post 158104)

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

Code:

        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.