As web developers we are tempted to be general about our use or the request object and submitted parameters. The temptation to access Request[“someKey”] is high because it frees us from wondering whether MyPage.aspx was posted to using POST or GET and we might also convince ourselves that it’s more flexible because it means that both POST and GET would work. Well, it would do something, that’s for sure. But do we always get consistent results?

Consider:

string val = Context.Request["MyKey"];

Where does val come from? HttpRequest class scans QueryString, Form, Cookies and ServerVariables of the request object, in that order. First match gets you an answer. This also means that if a query string param named "SID" exists and a form field named "SID" exists, you will get the query string value (GET). The implementation essentially is

// implementation detail
public string this[string key]
{
get
{
string returnValue = this.QueryString[key];
if (returnValue != null)
{
return returnValue;
}
returnValue = this.Form[key];
if (returnValue != null)
{
return returnValue;
}
HttpCookie cookie1 = this.Cookies[key];
if (cookie1 != null)
{
return cookie1.Value;
}
returnValue = this.ServerVariables[key];
if (returnValue != null)
{
return returnValue;
}
return null;
}
}

Note here that as a last resort, the key is looked up against the ServerVariables collection. That’s makes me a bit uneasy. Not that I ever wanted a form variable named “USER_AGENT” but now that I know it scans for it, I’ll be careful about my variable naming.

Moving on, consider:

string val = Context.Request.Params["MyKey"];

Where does val come from? You wouldn't necessarily know. Params is built on first request, and accessed throughout the lifetime of the HttpRequest object. Building it is done by creating a new collection, which includes all 4 request sources, as listed below. Since it is a Collections.Specialized.NameValueCollection type, if a key exists in more than one of the 4 sources, the value would be appended as a comma separated list. So if "PID" was both a query string GET parameter (say value 123) and a form POST variable (say value 456), then

(Request.Params["PID"] == "123,456") == true;

private void FillInParamsCollection()
{
//_params is the underlying collection supporing the Params property 
this._params.Add(this.QueryString);
this._params.Add(this.Form);
this._params.Add(this.Cookies);
this._params.Add(this.ServerVariables);
}

What can we conclude from these observations?

1. If you called Request.Params, even once, you now created a new collection, allocating enough memory to hold ALL parameters from the various sources. If you know what the parameter's source is, you would be more efficient using that source collection directly. If you or your buddy working on the same code tree called Request.Params, however, the hit is taken, and subsequent references would not re-allocate collections.
2. Precedence of parameters applies when you call Request[key], but not when you call Request.Params[key] .
3. The effect of Params collection sporting a comma separated list is a double whammy:
   1. Upon insert, (Request.Params[“myKey”] = “myvalue”) an arraylist is created and appended to (repetitive allocation for each value).
   2. Upon assignment from Request.Params:

i. If the {string [] GetValues()} method is used, the ArrayList gets converted to a string [] object just for you each time (it’s not cached or preserved as an internal variable).

ii. If the {string Get()} is used, private static string GetAsOneString(ArrayList list), a string builder object is created just for you to concatenate the values and return them to you.

Although both methods are coded as efficiently, neither gets you a reference to an existing object, and both have to create another object and copy data to it on the fly each time. For that reason, it’s less efficient than if you knew exactly the source of your parameter and used that collection as the source.

This issue can manifest if your application combines things like flash movies, remote static HTML forms submitting to your site (think affiliate marketing programs) and various hard coded links which were created to a specific form from menus, site maps and other corners of your application. When you work with forms designed by visual studio and sue asp form controls you generally don’t encounter this because then you have access to strongly typed properties. More often than not I have run across a hybrid of asp form controls and hand coded links from CMS parts of your app or other rouge text links so it’s worth knowing and paying attention.

To reign in the parameters and ensure no rouge parameters exist ever, I’d recommend creating a utility class that would wrap the Request object and use a set of well known parameters only which would encompass all usable parameter names.

/// ParamMarshal is a sample utility which wraps the Request object. 
/// It provides an easy way to eliminate ambiguity and define the 
/// source of POST and GET parameters for large web projects so that 
/// no parameter collision happens. Search your solution for any 
/// reference to the "Request[" or "Request." and replace it with a 
/// call to ParamMarshal.GetValue() 
/// 
namespace NH.Web.Utilities
{
public class ParamMarshal
{
public static string GetValue(WellKnownParam param)
{
string result = string.Empty;
switch (param)
{
// the first 5 are POST variables. No ambiguity. 
case WellKnownParam.FirstName:
case WellKnownParam.LastName:
case WellKnownParam.Password:
result = HttpContext.Current.Request.Form[param.ToString()];
break;
// the following 2 are GET variables. No ambiguity either. 
case WellKnownParam.AffiliateID:
case WellKnownParam.Keywords:
result = HttpContext.Current.Request.QueryString[param.ToString()];
break;
default:
/// this should never happen., because you should 
/// take care of every member of the WellKnownParameter 
/// Specifically, do NOT put 
/// return HttpContext.Current.Request[param.ToString()].. 
throw new Exception(
"Programmer forgot to handle " + param.ToString());
break;
}
return result;
}
public enum WellKnownParam
{
FirstName,
LastName,
Password,
AffiliateID,
Keywords
}
}
}

We all know by now that .Net has a garbage collector, and have hopefully also learned about the 2 modes of GC and the proper use of Dispose() and object finalization. Great! So we took care of early as possible release of resources and maybe take advantage of some object pooling or some other memory reuse.

Now we go ahead and write a whole bunch of code, but when we fire up performance monitor we see that the % time in GC is high, or spikes a lot, or that the application has occasional “hangs” where the CPU spikes together with GC and wonder – what is happening there?

It’s possible that you are encountering excessive garbage generation. Worse off, you are doing it by trusting the very reason you like the .Net framework – those nice collections and list structures that come with it or StringBuilder which you use so diligently after hearing that strings are immutable and repetitive catenation is bad. Here is the whole point of this article: Please use the overloaded constructor that takes (int Capacity) as a parameter.

So instead of

// optimistic, often wrong

StringBuilder sbNaive = new StringBuilder();

ArrayList myListNaive = new ArrayList();

Consider:

// realistic, better guess than waste

StringBuilder sb = new StringBuilder(83);

ArrayList myList = new ArrayList(798);

If you don't know the exact number of items, and the number of items can be bigger than 16, guess!

Why? Most all collections in System.Collections.* use an algorithm whereby the underlying array of objects grows to double its previous size when the initial “vanilla” capacity is exceeded. Well, it doesn’t actually grow. A new array is created whose size is double the existing one. Then the object references from the original array are copied to the new bigger array and then the old array is discarded. So each time the structure has to grow, a fixed length array is released to GC’s graces. GC kicks in every x number of bytes worth of abandoned memory accumulates It would also kick in if the fragmentation of your heap generation is such that a new object won’ fit. Excessive generation of temporary useless objects would induce GC more often. I call the discarded bytes useless because the sole reason for their existence was to hold references along the way but they are not eventually used and do not serve your application.

Allocation of memory on the managed heap is fast in human terms, but is a waste - GC inducing waste. This phenomenon can manifest if your application has high transaction rate and data objects keep popping into existence, loaded from databases, middle tiers into web pages, services or what have you. It also can manifest if you build many strings on the fly and are not careful about it.

Let’s examine System.Text.StringBuilder. It’s recommended as an alternative to repetitive catenation of strings (as well it should be!). It happens to start with and underlying 16 bytes length string. If you were to actually concatenate a string of length 33 byte by byte, you would have allocated the underlying string 3 times, creating 2 objects for the GC to collect:
16 bytes, then 32 bytes then 64 bytes. Total allocation used 33. Waste = (16 + 32 + 64) - 33 = 79 bytes. In this example, 16 + 32 bytes were total waste. 31 bytes were allocated but not used, so memory consumption is higher than it should have been but you wasted more than you over allocated.

If we wanted a string for some cache key that is for example: “MID1234561|CID102|SID445|R789235612|WHO_KNOWS_WHAT|2006-08-08-1245”
We would now use StringBuilder to generate the string, because we know strings are immutable. We don’t set a capacity on StringBuilder constructor and just use .Append () method to get various properties of our object into the string. Total string length 66. The allocations would be 16, 32, 64, and 128. That’s 3 wasteful GC objects and 128 – 66 = 62 bytes that were allocated along the way and were never used. Do this 10 times on a page that gets 10 million hits a day and you create a constant stream of 7kb per second, and you’d hit GC’s threshold no later than once every 35 seconds or so.

One wants to be conservative with resources, so a concern is not to allocate too much memory unless we need it. The bigger concern here is grabbing memory unintentionally and making no use of it. GC should be minimized if you want to maintain performance, or else it will block your thread and freeze your app. If you start seeing memory get recycled on you because memory is scarce, then you want to tackle over allocation waste as well. But memory is cheap these days, so I say: Spend $100 and get another gigabyte of RAM.

In the beginning of this article, I recommended that if you don’t know how long your list is or eventual string is or something, you should take a stab and guess. Guessing and overestimating may beat the alternative often.

Say you have a collection of 18 - 24 widgets. You guess you need 20. Since the underlying structure of an ArrayList and most collections is a regular Object [] (straight c# array), you create ArrayList(20). If you end up only adding 18 items to your collection, you are out a total of 2 * sizeof(int). Not too bad, especially considering that the widget sizes are what would take most of the memory. And no need to re-allocate the underlying array, so no object was created for nothing. The widgets themselves, typically classes (reference objects), would be allocated on heap anyway so no gain, no pain either. But you allocated once, and GC didn’t get an unused wasted object. ArrayList allocates Object [16] by default, so if you didn’t guess and add 18 objects, you would have wasted 1 array of size 16 * sizof(int), because the original one was not enough, and the content of the original gets copied over to the new one.

When high item count or bytes are at play, guessing gets better. The table below shows:

1. Structure Length: a structure size (be it bytes or items in a list)

    

2. GC Objects: The minimum number of abandoned objects to GC (that is allocation that got chucked to GC because a bigger structure was needed)

    

3. GC Objects size: the cumulative sizeof(int) wasted by the GC objects

    

4. Avg. Eventual Item count – a simple average of items that would have resulted in such a structure if no initial allocation was made.

    

So consider a structure of about 700 items. You didn’t know exactly how many you would have, you guess 500. You populate it with 700, 500 = wasted, 1000 – 700 = 300 over allocated. GC called once for nothing. You guess 900 (still off by 200 from reality, but to the plus size this time): You populate it with 700, 200 over allocated, no GC until your useful object is done.

Using MemoryStream? That's just a byte array. And it grows by doubling - more or less. If you don't specify the size, it allocates no bytes. Then on first hits, it allocates enough bytes for the write. If you write more data but still less than 100 bytes, 100 bytes get allocated. Past 100 bytes, it's the double the size thing all over again.

HashTable? Starts off with a size that's a prime number larger than some load factor float thing, and then grows by finding the next prime number that's larger than (twice the current # of buckets) + 1. This is even worse, since the prime series can have large "holes" between the 2 next primes and might end up allocating some arbitrarily larger array because of that. OK, it's a bit more complex than this, and there is some fancy pointer manipulation under the covers for the copying and reference swapping, but no great news as far as predicting how much memory you really needed to begin with. Also, both growth of the underlying bucket list and insertion of a colliding items cause a re-hash of keys, which is not GC but costs you time.

So by now hopefully you are convinced or mildly interested in specifying a size for your structures when calling its constructor. Does this really affect you? Where do we see all these objects created and populated on the fly? A common approach to tier separation is that the DB or DAL layer reads data tables (horrendously wasteful objects, unless you really need them, but more on that in a different article) and then populates a strongly typed collection / class from the table by reading each row, creating the strongly typed object and shoving it into a HashTable or dictionary or something of the sort. Tier separation is a good thing. Just remember to specify the capacity. You can get it from Rows.Count() or its equivalent.

String concatenation is very common for dynamic content on websites. Many developers use on the fly strings mad up of static data and some session, profile or transient data. This includes shopping carts, personalization aspects and others. If the eventual string is displayed as HTML or body text, I’d actually advise to defer any string concatenation and override the Render() event. There you can append to the actual output stream and waste no memory at all. Output stream under IIS has a buffer of about 30kb initially if I recall so render away! By creating a whole bunch of properties that are strings and assigning them to literals you waste memory in the creation of these strings, and the base class Render method would just use the eventual string. The standing recommendation of using StringBuilder is very sound - all you need to do is remember to initialize it to a sane capacity initially.

In conclusion, beware and be aware. Not everyone encounters GC problems, and the benefits of RAD are numerous. If you do, however, have data intensive applications with high transaction rates, consider reducing the amount of objects GC has to handle by any means that make sense in your application.

So I wrote the thing up. Compared with a fairly common alternative, a run of the more type safe and render friendly template took 260 ms to merge 10k iterations vs. 480 ms for the alternative. In addition, the alternative went through almost twice the allocations (meaning more GC would result).

I'm kind of pleased that this is faster than the alternative, but am going to do some more thinking of a better way.  A 46% reduction is nice, but it's just under twice as fast. Still, the benefits of a cached template and token/key checking beats the alternative.

Toying with the idea of a strongly typed template leads to a dead end pretty much. Sure, one could dynamically emit a class that exposes the token names as properties, but then how would you bind to these in compile time? since the tokens are NOT known at compile time, the programmer using the class would have to populate a name value pair in some fashion, so that at run time the binding could be made.

//------------------------------------
namespace Nuri.FasterTemplate
{
    public interface IFasterTemplate
    {
        string ID { get; }
        void Render(System.IO.TextWriter writer, IRuntimeValues runtimeValues);
        IRuntimeValues GetRuntimeValuesPrototype();
    }
}
//------------------------------------
namespace Nuri.FasterTemplate
{
    public interface IRuntimeValues
    {
        bool AddValue(string tokenName, string value);
        bool AddValues(IEnumerable values);
        string[] GetAllowedValues();
        IRuntimeValues GetCopy();
        bool IsAlowed(string tokenName);
        string this[string tokenName] { get; }
        string ID { get; }
    }
}
//------------------------------------
namespace Nuri.FasterTemplate
{
    public static class FasterTempateFactory
    {
        public static IFasterTemplate GetFasterTemplate(TokenConfiguration config, ref string template)
        {
            string id = Guid.NewGuid().ToString();
            TemplateParts templateParts = processTemplateParts(id, config, ref template);
            IRuntimeValues runtimeValuesPrototype = processTokens(id, templateParts);
            IFasterTemplate result = new FasterTemplate(id, templateParts, runtimeValuesPrototype);
            return result;
        }
        private static IRuntimeValues processTokens(string id, TemplateParts templateParts)
        {
            RuntimeValues result = new RuntimeValues(id);
            for (int i = 0; i < templateParts.Count; i++)
                if (templateParts[i].IsToken)
                    result[templateParts[i].Value] = string.Empty;
            return result;
        }
        private static TemplateParts processTemplateParts(string id, TokenConfiguration config, ref string template)
        {
            TemplateParts result = new TemplateParts();
            char currentChar;
            bool isToken = false;
            StringBuilder sbText = new StringBuilder(template.Length / 2);
            StringBuilder sbToken = new StringBuilder(64);
            for (int idx = 0; idx < template.Length; idx++)
            {
                currentChar = template[idx];
                if (currentChar == config.TokenStartMarker)
                { isToken = true; result.Add(new TemplatePart(sbText.ToString(), false)); sbText.Length = 0; }
                else if (currentChar == config.TokenEndMarker) { isToken = false; result.Add(new TemplatePart(sbToken.ToString(), true)); sbToken.Length = 0; } else { if (isToken)                        sbToken.Append(currentChar); else                        sbText.Append(currentChar); }
            } if (isToken == true) throw new ArgumentException("Template has unclosed token marker"); if (sbText.Length > 0) result.Add(new TemplatePart(sbText.ToString(), false)); return result;
        }
    }
}
//------------------------------------
namespace Nuri.FasterTemplate
{
    internal class FasterTemplate : IFasterTemplate
    {
        private string _ID;
        private TemplateParts _TemplateParts;
        private IRuntimeValues _RuntimeValuesPrototype;
        internal FasterTemplate(string ID, TemplateParts templateParts, IRuntimeValues runtimeValuesPrototype) { _ID = ID; _TemplateParts = templateParts; _RuntimeValuesPrototype = runtimeValuesPrototype; } public IRuntimeValues GetRuntimeValuesPrototype() { return _RuntimeValuesPrototype.GetCopy(); } public string ID { get { return _ID; } }
        public void Render(System.IO.TextWriter writer, IRuntimeValues runtimeValues)
        {
            if (runtimeValues.ID != this._ID) throw new ArgumentException("The runtime values supplied are not compatible with this template! Ensure you got the runtime values object from the template with ID " + this._ID); for (int i = 0, count = _TemplateParts.Count; i < count; i++)
            {
                TemplatePart part = _TemplateParts[i]; if (part.IsToken) { writer.Write(runtimeValues[part.Value]); }
                else
                {
                    writer.Write(part.Value);
                }
            }
        }
    }
}
//------------------------------------
namespace Nuri.FasterTemplate
{
    internal class RuntimeValues : Nuri.FasterTemplate.IRuntimeValues
    {
        private Dictionary<string,string> _AllowedValues;
        internal string _ID;
        internal RuntimeValues(string ID, int capacity)
        {
            _AllowedValues = new Dictionary<string, string>(capacity);
            _ID = ID;
        }
        internal RuntimeValues(string ID) : this(ID, 0x10) { }
        internal Dictionary<string,string> AllowedValues
        {
            get { return _AllowedValues; }
        }
        public string[] GetAllowedValues()
        {
            string[] result = new string[_AllowedValues.Count];
            int i = 0;
            foreach (string key in _AllowedValues.Keys)
            { result[i++] = key; }
            return result;
        }
        public bool IsAlowed(string tokenName)
        {
            return _AllowedValues.ContainsKey(tokenName);
        }
        public bool AddValue(string tokenName, string value)
        {
            if (_AllowedValues.ContainsKey(tokenName))
            {
                _AllowedValues[tokenName] = value;
                return true;
            }
            else
                return false;
        }

        public bool AddValues(IEnumerable values)
        {
            bool result = true;
            foreach (KeyValuePair<string, string> pair in values)
            {
                result = result && this.AddValue(pair.Key, pair.Value);
            }
            return result;
        }
        public string this[string tokenName]
        {
            get
            {
                return _AllowedValues[tokenName];
            }
            internal set
            { _AllowedValues[tokenName] = value; }
        }
        public IRuntimeValues GetCopy()
        {
            RuntimeValues result = new RuntimeValues(this._ID, _AllowedValues.Count);
            foreach (string key in _AllowedValues.Keys)
                result.AllowedValues[key] = string.Empty;

            return result;
        }
        public string ID
        {
            get { return _ID; }
        }
    }
}
//------------------------------------
namespace Nuri.FasterTemplate
{
    internal struct TemplatePart
    {
        public bool IsToken;
        public string Value;
        public TemplatePart(string value, bool isToken)
        {
            this.Value = value;
            this.IsToken = isToken;
        }
    }
}
//------------------------------------
namespace Nuri.FasterTemplate
{
    class TemplateParts : List<TemplatePart> { }
}
//------------------------------------ 
namespace Nuri.FasterTemplate
{
    public struct TokenConfiguration
    {
        public readonly char TokenStartMarker;
        public readonly char TokenEndMarker;
        public TokenConfiguration(char tokenStartMarker, char tokenEndMarker)
        {
            TokenStartMarker = tokenStartMarker;
            TokenEndMarker = tokenEndMarker;
        }
    }
}

I'm toying with a class that will allow for efficient token replacement at runtime.

Why re-invent the wheel?

1. Its fun
2. A bare class that does just this is rare
3. Absent a class like this, people just use all kinds of string manipulation techniques that can be slow and sluggish.

What am I out to solve? Let's say your website supports some notion of a CMS. So you let some users publish pages / content by filling in a form and storing the content in the db. Next usually comes the request that special variables can be planted in the content. This includes ads, formatting, dynamic links, personalization data etc. The first reflex is to just use string replacement. But if the content is not the whole page, the tendency is to assign the string to a literal or somehow just create a string field in your page and then assign it to some code in front control. The issue with this is that at the very best, the input string (template) is scanned every time in order to determine where the token markers are. At the very worst this is combined with string thrashing and ends up being a wasteful string concatenation exercise. Me thinks a factory class TemplateFactory can generate an immutable template class. That class can be cached for a long time. The template innards would all be private and hidden. They would consist of all the static parts and all the "holes". The template will be in itself a factory, letting a user get an instance of a RuntimeValue object. The runtime value object will support a .Add(TokenName, TokenValue) method, which would check the token names and be bound to the originating factory (the template that created it). This way, you get some runtime checking of invalid token assignments. The template would expose a method Render(writer, runtimeValues) . The render method would be the one merging the template with the runtime values. Notably, there would NOT be a string MergeValues(values) call. That's because strings are immutable and storing the merged string at any scope is a waste. The only reason one would need to store it is for later use in a stream context (IIS response stream, mail message, file etc). If this pains anyone, the use of StringWriter is recommended. But the intended use of this scheme is to plant the Render() call somewhere in the OnRender() event equivalent of your application. The idea is that the object would both enforce a correct (IMHO) deferral of merging to the presentation time, and implement an efficient algorithm for fast merges. The instance creation is going to bear the grunt of parsing the template and scanning for token markers. If a CMS system is the target app, it can pre create these runtime objects and keep them in memory. A template object would specifically NOT be created each time you need to merge. Only the lightweight RuntimeValues need to be gotten from a factory and populated each time, because these are the real runtime instance variants. The rest of the template is "static".