For a while, I was writing blog posts around identifing the fastest method for accomplishing particular goals. They can be found on my blog under the "performance stub" tag. This is the repository where I will collect all of the test code along with the framework I used to run the tests.
As I code, I like to make some light notes of alternatives while driving forward with the first implementation that makes it from my brain to my fingers. When I get the chance, I can go back and flesh out the two versions and drop them into some basic Stopwatch timing to determine which is better in terms of raw speed. Factoring those results with clarity of code, I have a method I will likely choose the next time I need the same feature.
Don't take these test results as any end-all answer. These are the numbers I got on some random computer I was using at the time. Feel free to use them as a starting point. If you are really digging into performance, you already know that everything can change once you put the code in question in its natural surroundings (e.g., Windows .NET vs. MonoTouch) or put it under load.
- Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz [NOTE: Windows 8.1 running under VMware Fusion]
- Cores: 4
- Current Clock Speed: 2295
- Max Clock Speed: 2295
Tests (so far)
Getting object properties by name at runtime (concrete type)
Getting object properties by name at runtime (dynamic ExpandoObject)
Getting object properties by name at runtime (anonymous type)
Getting first subtype item from a list
Getting all subtype items from a list
Lookup tables have taken the lead over byte manipulation, especially if you are willing to play in the unsafe realm. Basically, there is some form of precomputing what any given nibble or byte will be in hex. Then, as you rip through the data, you simply look up the next portion to see what hex string it would be. That value is then added to the resulting string output in some fashion. For a long time byte manipulation, potentially harder to read by some developers, was the top-performing approach.
Your best bet is still going to be finding some representative data and trying it out in a production-like environment. If you have different memory constraints, you may prefer a method with fewer allocations to one that would be faster but consume more memory.
If you find something wrong with this stuff or have recommendations for the testing framework, don't hesitate to bring it up. If you have a test idea that would add some value to the world, feel free to write up something that implements
IPerformanceTest and submit it. New issues and pull requests are always welcome. If you submit it, I will assume you don't mind it becoming part of this project and subject to its MIT license.
MIT license. If you do something cool with it, though, I'd love to hear about it.