Justins Fat Tire

In C# I have read a lot of debate over which way is the best way to do String Concatenation.  I have often read never ever use String1 + String2 due to the memory allocations and time constraints.  I decided to run some tests on the various way of doing String manipulation.  The table below shows the iterations, total times, and average times for some common way of doing string addition.  This was just a test of time, there was no memory consumption test.  All tests were doing adding 7 strings together that were stored in variable names.  There was no string a = "a" + "b";  It was all string a  = var1 + var2;  These were creating a single string for the listed iterations using the method(s) below. I was surprised to see the + method came out ahead in all the tests.  String builder came in a close second.  String.Format was extremely slow but allows for localization which is another story. iterations String + average ...

Today I'm getting a bit into data structures. Recently I've found a need to store a large amount of records (16 million) in memory as a sort of cache. I tried using databases, etc, but it was all too slow. I needed super fast access times, well under a millisecond to speed up a large application with many data look ups. I tried a linked list but while the insert times were great the look ups again were too slow. I finally settled on a binary tree. Building the tree is slow, several minutes, but this data doesn't change and gives me super fast look up times, around .005 ms. To achieve this I wrote a very simple binary tree class. It uses a node that is fit for my purposes. To make this class even better I would implement in generics with a node class that has to implement IComparable. This way you can make a binary tree for any type of class that can be compared. For now I'm hard coding the key/values for my specific needs. See the rather large code block bel...

I recently ran into a situation where I had to do some string manipulation. I had to replace some bad text with valid text. All this had to do with creating valid xml element names. So we had to string white space and some other invalid characters and replace them with valid xml element formatting. To do this we ended up using the Regex.Replace static method. Simply because there was some complexity involved that would have entailed using more then 1 String.Replace call when we can do it all with one regular expression. This caused some discussion about how heavy the regex class is and when to use it. I decided to do some testing and these are my results. First the code static void Main( string[] args ) { // this is our test value string testValue = "This is a test string"; int count; // run the regex replace DateTime regexStart = DateTime.Now; for( count = 0; count < 10000000; count++ ) { string newValue = Regex.Replace( testValue, ...

Ok so I'm working on a fairly large asp.net application. When we first started we were using DataSets for ease of use. However as the app has gotten large we're finding DataSets are very heavy in memory and filling them from the database takes a lot of time. So after some research I found DataReaders are the best thing to use. We use the data access blocks (3.1) from microsoft and swithing from ExecuteDataSet to ExecuteDataReader saved almost 2 seconds. It was a huge savings. Switching to datareaders isn't without some problems. In some instances we need hierarchical presentation and datasets work very well for that. Also some of our classes expose dataviews as properties and that creates some problems. However most of this can be overcome with some better OOD. And when using datareaders always always always close them! So use the using statement in c# which closes the datareader when done. So using the data acccess blocks with a stored procedure here is some sample code of...