No probs. Was just making sure you're aware that release mode + no debugger can make substantial impact on simple synthetic tests like this. But sounds like you are :) I can't think of any other obvious way to improve the lookup performance further. The inbuilt dictionary is pretty fast. It's often difficult to beat. I've made some dictionary like structures that are faster GenericHashTrie for example but they have significant downsides compared to the generic dictionary.

Your test is invalid

for (int i = 0; i < 1000000; i++)
{
// 10ms - int x string
string s;
dict.TryGetValue(5, out s);
}

You never use the value of string 's' inside the loop. This means the compiler can optimize it out. Unless your running it in debug mode with debugger attached The performance you get running in release mode without debugger attached can be massively different This test is to trivial to be good measure of real performance. Also your looking up the same key every time '5'. The performance can change significantly depending on what key you're looking up

It will probably be difficult to beat the inbuilt hash code functions for the general case however there might be something about your specific data that you can exploit to make a stronger hash function Example: If you know the first 4 chars of your strings are nearly always unique, you could just turn those into the 32 bit hash. This would save .NET framework from hashing the entire string so it will be faster. It will also be stronger because you used knowledge specific to your data (Eg, the first 4 chars are enough) If there are any features of your keys like above you can exploit. The chances of doing better than the inbuilt stuff will be much better Cheers Matt

You might also want to post the code for your benchmark so we can check if it's valid It's very easy to mess up tests like this :)

If you want your gethashcode method to be faster than the inbuilt one you'll need to a.) Make sure that collisions are as rare as possible for your specific data, this can be done via implementing a custom hashing algorithm to suit your data b.) Ensure that GetHashCode is very fast in terms of cycles Because you're just calling the GetHashCode on string and type above. It's going to be no faster or better than the inbuilt ones. You'll need to come up with a hashing scheme that's faster and stronger (Less frequent collisions) than the inbuilt ones.

Try implementing your own fast ToHash and Equals methods perhaps

All encryption is lossless? You have to be able to undo it back to the original :P

What raw tcp client? The GPS device is accessed via TCP out of the box? Not USB or RS232 or something? WCF supports TCP out of the box; you don't need to write any code http://msdn.microsoft.com/en-us/library/system.servicemodel.nettcpbinding%28v=vs.110%29.aspx[^]

Does seem kinda dumb to have them the wrong way around Windows has had them the same way around for way more than a decade

Unless you have 5+ years experience writing high performance TCP messaging servers Your code is going to be way, way, worse than what's in WCF and not as scalable. Unless you know how TCP buffers are managed by the kernel; why it's bad to use thread-per request; what overlapped IO is and what an NT fiber is Then you're 0% the way qualified to write your own TCP server and shouldn't even attempt it. Writing a high performance 'good' tcp server implementation is 1 to 5 years development effort on its own. You can write a raw sockets server using a thread-per-request model in like a few hours Sure; But you'll start running into issues with many clients pretty rapidly. If you want to reduce the packet size of WCF. Use google protobuff binding for WCF. It makes insanely tiny packets. There's really no need to cause some other poor developer to work on a naive server implementation when there are very fast and very scaleable tools (WCF, ZeroMQ) that take care of all of this for you Writing a custom tcp server is pretty much like going "I'd like to write my own kernel scheduler" It's easy to get going, takes a lifetime to do it right though. That's why ZeroMQ and WCF exist.

http://blog.shutupandcode.net/?p=1085[^] That guy got 30,000 messages/sec just out of the box without any tweaking You need more than this?

WCF scales up to thousands to tens/thousands/millions messages per second It's not very likely a home grown TCP server will perform as well without years of development effort Edit (Some, not all) of the difficulty is expressed in this two parter Design and Implementation of a High-performance TCP/IP Communications Library[^] AND Design and Implementation of a High-performance TCP/IP Communications Library[^] Realistically this is only covering a small fraction of what is required though Seriously; save your self weeks/months of work and just use a library

Yeah DataProtection api is the way to go

You were just given a bunch of references appropriate to your problem

Writing a high performance tcp server is very tricky. You have to have a good understanding of overlapped IO. Managing kernel receive buffers, and a huge mess of stuff that's not obvious from simple 'my first tcp server' type articles on the internet Strongly suggest you use professional messaging wrapper around tcp Eg; ZeroMQ is something that hides a lot of these details from you http://zeromq.org/[^] Another possible recommendation is WCF with the tcp binding I would not write your own tcp server just for the hell of it; it will no doubt be terrible compared to the above products Matt.

Microsoft uses all of fired, triggered and raised interchangeably Example from the "Event" article on the MSDN "An event often has no custom data; the fact that the event was fired provides all the information that event handlers require. In this case, the event can pass an EventArgs object to its handlers. The EventArgs class has only a single member, Empty, that is not inherited from System.Object. It can be used to instantiate a new EventArgs class." "An event delegate is used to define the signature of the event. A particular event delegate typically corresponds to a particular event data class. By convention, events in the .NET Framework have the signature EventName(sender, e), where sender is an Object that provides a reference to the class or structure that fired the event" I guess you better get MS on the phone and tell them all about the sand in your knickers

Reason it may have not been subscribed: 1. You were using the visual studio forms designer; moved the control, cut and paste, played with the properties or otherwise changed the control in the designer and forgot to subscribe your method to the relevant event in the UI designer and the emitted *.designer.cs was missing the subscription you wanted 2. You were subscribing by hand without knowing what you are doing and subscribed to the event in a bad place in the applications life cycle. Eg, after the event had been fired. Solution to 1 and 2 as with all things is to know what you are doing. The most important thing to do is obviously identify the the place in your code where you subscribe to the event. If you can't locate where you subscribe to the event; then it's not surprising methods don't get called when you expect them to and you need to read more about how events work and .NET in general.. If you do know where you are subscribing and you've checked using the debugger that it gets called at an appropriate time in the applications life cycle then it's DevEx's problem as they're not triggering the event reliably, which is probably unlikely.

First thing. Those signatures are totally identical. So I don't know what you're complaining about public void foo(Color x); is identical to public void foo(System.Drawing.Color x) If you are importing the System.Drawing namespace that is. I think java has namespaces too. Second thing. When it wasn't firing, did you check that you are actually subscribing/wiring up xrInvAllegations_BeforePrint method to an event? I strongly suspect what you probably did was accidentally not subscribe to the event. Then you probably used the visual studio IDE to create a 'new' event via using the forms designer. The forms designer probably subscribed to the event for you, and hence xrInvAllegations_BeforePrint now gets called correctly. Which fixed your problem (In a stupid round about way) On the non firing version. I'd go check you actually have code somewhere that looks like someClass.SomeEvent += xrInvAllegations_BeforePrint; If you don't, it's pretty obvious why it's not getting fired :P Functions and methods don't magically get called unless you tell something you want them to be called.

Just use the .NET Threadpool or task parallel library Does the queuing for you

Totally agree; The entire system hinges on validating the signature before you execute it. My main point was more than a hand-rolled solution based only on an MD5 hash doesn't provide remotely the same features as strong signing does. However; there are cases where run-time authentication using the strong signing is useful. Consider following example; You can easily grant .NET security permissions based on a particular publisher. I grant only assemblies published by "MattyCo" access to read/write from MattyCo's super secret drive If you decompile and recompile A with no or a different signature; the newly recompiled assembly they've sneakily placed on my machine isn't signed by MattyCo, can't access the drive, and no harm is done. So I got a fair amount of benefit there using the inbuilt run-time authentication that .NET/Windows provides (Also you obviously get none of these benefits just by using an MD5 sum..)