views:

140

answers:

3

Hello, I have a MMORPG emulator, this means it will be handling packets quite a bit. Currently, I am using pointers for this, as I think when used correctly, they can speed up my server, however I've got two friends, one is telling me to use pointers, he thinks I can use them without running into trouble, my other friends says I should not use pointers, as they could make my server crash, they are unsafe, and they aren't easy to manage.

I use structs for my packet structures, so e.g. I could get its type using the following line: Ptr->Type;

What do you think?

+4  A: 

If you know what you are doing, then using pointers as you mentioned, would be a lot faster than any other form of de/serialization.

leppie
+7  A: 

In a way, they're both right. If you handle them propertly, pointers are much faster. On the other hand, if you don't handle them correctly, they can cause all kinds of problems.

If you think you've got a handle on it (and your friend(s) who is (are) knowledgable about pointers are willing to help you) go with pointers.

AllenG
+1 because it's true, but also because I'm pretty sure there is a pun in there about having a handle on pointers.
fire.eagle
@fire.eagle: I'd take credit for it, but I didn't even see it 'til you pointed (*groan*) it out.
AllenG
I see, do you also agree that could make my project messy, or do you disagree?
Basser
@Basser: The code its self should wind up being fairly clean, because pointer notation isn't that bad. However, logically, it will be a pain. If you go the pointer route, document EVERYTHING. You will thank yourself if you ever have to take a few weeks off of the project. Otherwise, you'll come back and will have forgotten what everything does. Then you're in trouble.
fire.eagle
@Basser. It really depends on your definition of "messy." As long as you're grouping your code properly, using `#region` definitions, etc., your code shouldn't be messy from an aesthetic/readibility standpoint.
AllenG
Imagine the following, my emulator is going open-source, which means less experienced people will be reading the code, they won't be editing it, because this is just imaginary, would they be confused by the pointer usage, or would they not understand what exactly it does, but accept it and continue without getting confused?
Basser
@Basser: The main thing is not start throwing valuetypes around.
leppie
_How_ much faster is `much faster`?
Allon Guralnek
@Allon Guralnek: "Profile, profile, profile" but enough that the couple of semi-professional game developers I know (they make decent money developing and selling their own XNA games) swear that pointers are the only way to go.
AllenG
@AllenG: The distance between a belief and the truth varies wildly.
Allon Guralnek
@Allon Guralnek: Indeed, and if they hadn't made enough money last year that their "real" jobs were superfluous (sp?), I'd say "meh." However, they __did__ make enough money that their "real" jobs were superfluous.
AllenG
@AllenG - The `BitConverter.ToX()` methods already implement pointers internally. They prevent you from making silly mistakes and kicking yourself in the foot as well as providing self-descriptive code, and the "massive performance difference" is an extra method call - hardly something to celebrate.
Mark H
+8  A: 

I think you should probably test the performance with and without pointers, and then see for yourself if the gains in performance, if any, are worth the extra complexity of using pointers.

Chances are you'll find most of the your porgram's time is spent sitting there twiddling its thumbs doing nothing while waiting on network traffic.

ShaderOp
Good advice. If nothing else, best to get it working without pointers, so that there's a baseline to compare both performance and correctness.
Steven Sudit
+1: In short, [avoid premature optimization](http://stackoverflow.com/questions/385506/when-is-optimisation-premature)! The CLR is pretty damn fast, you may find that you'll never have to resort to unsafe code.
Allon Guralnek
+1: Also, good point that this would most likely wind up being an IO bound application, not CPU bound.
fire.eagle