Here is the code I'm using:

RenderTargetBitmap image = new RenderTargetBitmap(m_width, m_height, 96, 96, PixelFormats.Pbgra32);
                        
image.Render(m_visual);

string pngFile = fileName + ".png";

using (FileStream stream = new FileStream(pngFile, FileMode.Create))
{
    PngBitmapEncoder encoder = new PngBitmapEncoder();

    encoder.Frames.Add(BitmapFrame.Create(image));
    encoder.Save(stream);
}

string xpsFile = fileName + ".xps";

using (Package container = Package.Open(xpsFile, FileMode.Create))
{
    using (XpsDocument xpsDoc = new XpsDocument(container, CompressionOption.Maximum))
    {
         XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(xpsDoc);

         VisualPaginator page = new VisualPaginator(m_visual, m_width, m_height);

         writer.Write(page);
    }
}

 Although XpsDocumentWriter can directly handle an Visual as input, there is no easy way to specifiy a custom page size. So I'm using a VisualPaginator class:

public class VisualPaginator : DocumentPaginator
{
    Size   m_size;
    Visual m_visual;

    public VisualPaginator(Visual visual, double width, double height)
    {
        m_visual = visual;
        m_size   = new Size(width, height);
    }

    public override IDocumentPaginatorSource Source 
    {
        get 
        { 
            return null; 
        }
    }

    public override DocumentPage GetPage(int pageNumber)
    {
        Rect box = new Rect(0, 0, m_size.Width, m_size.Height);

        return new DocumentPage(m_visual, m_size, box, box);
    }

    public override bool IsPageCountValid
    {
        get 
        { 
            return true; 
        }
    }

    public override int PageCount
    {
        get 
        { 
            return 1; 
        }
    }

    public override System.Windows.Size PageSize
    {
        get
        {
            return m_size;
        }
        set
        {
            m_size = value;
        }
    }

}

But actually, if all you want is concatenating strings, there is a more efficient way of doing so, the String.Join method. String.Join is more efficient in both memory and CPU. Here is a test program:

 const int sLen = 30, Loops = 5000;
 
 System.Diagnostics.Stopwatch watch = new System.Diagnostics.Stopwatch();
 
 string sSource = new String('X', sLen);
 string sDest = "";
 
 // Time string concatenation.
 // 
 watch.Restart();
 for (int i = 0; i < Loops; i++) sDest += sSource;
 watch.Stop();
 Console.WriteLine("Concatenation took {0,8:N3} ms. {1} chars", watch.Elapsed.TotalMilliseconds, sDest.Length);
 
 // Time StringBuilder.
 // 
 watch.Restart();
 System.Text.StringBuilder sb = new System.Text.StringBuilder(sLen * Loops);
 for (int i = 0; i < Loops; i++) sb.Append(sSource);
 sDest = sb.ToString();
 watch.Stop();
 Console.WriteLine("StringBuilder took {0,8:N3} ms. {1} chars", watch.Elapsed.TotalMilliseconds, sDest.Length);
 
 // Time String.Join.
 // 
 watch.Restart();
 string[] list = new string[Loops];
 for (int i = 0; i < Loops; i++) list[i] = sSource;
 sDest = String.Join(String.Empty, list, 0, Loops);
 watch.Stop();
 Console.WriteLine("String.Join took {0,8:N3} ms. {1} chars", watch.Elapsed.TotalMilliseconds, sDest.Length);
 

 Result:           

 Concatenation took 524.630 ms. 150000 chars
 StringBuilder took 0.426 ms. 150000 chars
 String.Join took 0.310 ms. 150000 chars

StringBuilder.Append takes 0.426 ms, copying string data twice. String.Join takes 0.310 ms, 27% less, copying string data only once.

StringBuilder uses 300 kb (30 * 5000 * 2) extra memory (in StringBuilder object), String.Join only uses 20 kb (5000 * pointer size) extra memory (in list).

So, if you only need to merge full strings, give String.Join a try. But StringBuilder is much much more powerful than just merging full strings.

If you're using StringBuilder and string concatenation a lot in your program, here are a few more things to ponder:

1. String.Concat(str1, str2) is a perfect string concatenation function for two strings, so do not use StringBuilder for two strings.
2. String.Concat(str1, str2, str3) and String.Concat(str1, str2, str3, str4) are almost perfect for concatenating three or four strings. Do not use StringBuiider for those cases.
3. Even if your code has complicated conditions to determine the strings to concatenate, as long as they're no more than 4 strings, it still pays to use string addition or String.Concat. You can have empty strings in the expression.
4. If you're concatenate an array of strings, String.Join(string separator, string[] value, int startIndex, int count) is the perfect method for them.
5. String Concat works best when all operands are string objects, non-objects will be boxed, non strings will be converted to String using ToString() method. Try to avoid such conversions. For example, path + '\\' + filename should be converted to path + "\\" + filename.
6. Do not use StringBuilder.Append(expr1 + expr2 + expr3), use Append(expr1).Append(expr2).Append(expr3) instead.
7. StringBuilder.ToString always generate a new string, be aware of possible string duplications. As comparison, String.Concat(str1, str2) does not generate a new string if either operand is empty.
8. When StringBuilder is out of memory, it allocates a new array of its current size, thus doubling its capacity. So on average, 25% space is wasted unless you specify the right size for it.
9. String.Format is implemented using StringBuilder.AppendFormat. Do not use it for simple formatting expressions like "{0}.{1}". It's much better to use expr1 + "." + expr2. Exception to this rule: the format strings need to be put into a resource code for things like customization/localization.
10. If StringBuilder is used often, consider recycle it for reuse, instead of re-creating them everytime. Be careful about possible threading issues. This is one of the optimization implemented in .Net 4.5.

Examples:

Bad

    String.Format("{0}.{1}", DeclaringType.FullName, Name)

Better

    DeclaringType.FullName + "." + Name

Bad:

                StringBuilder sb = new StringBuilder();
           
                bool first = true;
           
                if (GetFlag((int) PolicyStatementAttribute.Exclusive ))
                {
                    sb.Append( "Exclusive" );
                    first = false;
                }
                if (GetFlag((int) PolicyStatementAttribute.LevelFinal ))
                {
                    if (!first)
                        sb.Append( " " );
                    sb.Append( "LevelFinal" );
                }
           
                return sb.ToString();

This version is more costly for several reasons:

1. StringBuilder object is created.
2. Strings are copied when calling StringBuilder.Append
3. No size is given, so a smaller buffer is allocated automatically and then new allocations are made during Append calls.
4. A new string is always generated, even if it's just either "Exclusive" or "LevelFinal".

Better: if you use string + operator, there will be no StringBuilder object, no extra copy, no new buffer allocation, and best of all no new string is generated if it's just a single word.

                String p1 = null;
                String p2 = null;
                String p3 = null;

                if (GetFlag((int) PolicyStatementAttribute.Exclusive))
                {
                    p1 = "Exclusive";
                }

                if (GetFlag((int) PolicyStatementAttribute.LevelFinal))
                {
                    if (p1 != null)
                    {
                        p2 = " ";
                    }

                    p3 = "LevelFinal";
                }
           
                return p1 + p2 + p3;

public string[] Split(char[] separator, int count, StringSplitOptions options);

public string[] Split(string[] separator, int count, StringSplitOptions options);

Also String.Split methods are quite easy to use, there are hidde performance issues you should be aware of if you use them a lot:

1. The first parameter is an array of characters, or array of strings. If the same seperators are used over and over again, do not recreate the seperator array in each call; create once and reuse them.
2. The second paramter is maximum number of segments to return. If your scenario, pass-in the right value will limit the amount of work Split has to do.
3. If you do not want empty items, use StringSplitOptions.RemoveEmptyEntries so they do not need to be stored.
4. String.Split allocates internal workspace according to the length of the string, beware that this can create lots of garbage for long strings. Avoiding calling String.Split for really long strings.
5. If there is a high chance of the seperators not present in the string at all, check for this condition and handle seperately before calling String.Split.
6. As String.Split returns all the strings through the string array, they will be held in memory until there is no reference to the array. Try to limit this duration, otherwise more strings will be promoted to Generation 1 or Generation 2. It will be a good idea to null references to processed strings in the array.t
7. If you're using String.Split to process a large file or stream, there will be lots of duplicated strings. Try not to store those strings directly in your data structure. Instead, convert them to low cost versions, e.g. scalar values; or merge them into unique strings.
8. If your data is supposed to be not case sensitive, do not try to call String.ToLower/ToUpper on strings returned from String.Split, use non-case sensitive containers or non-case sensitive comparisons.
9. If you suspect String.Split is causing performance issue for your scenarios, measure performance using tools like PerfView.
10. If performance is still not optimal after these optimizations, avoid using String.Split or reimplement your own versions.

For one .csv file I'm generating, the report generation is essentially a big loop with tons of TextWriter.WriteLine calls:

static public void Version0()
{
    for (int i = 0; i < count; i++)
    {
        writer.WriteLine(
            "\"{0:x8}\",{1},{2},\"{3}\",\"{4}\",\"{5}\"",
            Data.Column1(i), Data.Column2(i), Data.Column3(i),
            Data.Column4(i), Data.Column5(i), Data.Column6(i));
    }
}

Profiling shows that TextWriter.WriteLine(string, object[]) forms a string first, and then calls WriteLine(string). But the latter allocates a char array for the string plus "\r\n", sending combined data to the basestream. It's nice that the lines would now be completed in a single call, but there is extra memory and CPU cost. Given that we're not writing to a console, and there is only a single writer, here is the next version:

static public void Version1()
{
    for (int i = 0; i < count; i++)
    {
        writer.Write(
            "\"{0:x8}\",{1},{2},\"{3}\",\"{4}\",\"{5}\"",
            Data.Column1(i), Data.Column2(i), Data.Column3(i),
            Data.Column4(i), Data.Column5(i), Data.Column6(i));

        writer.WriteLine();
    }
}

The change here is quite simple: splitting a single WriteLine call into two calls, char[] allocation is gone. Now the program is that TextWriter is creating a StringBuilder to form the output string, and string is converted to char[] before writing to the base stream. Given that it's important to our scenario, we can remove those extra cost too:

static public void Version2()
{
    StringBuilder sb = new StringBuilder(512);
    char[] buffer = new char[512];

    for (int i = 0; i < count; i++)
    {
        sb.Clear();
        sb.AppendFormat(
            "\"{0:x8}\",{1},{2},\"{3}\",\"{4}\",\"{5}\"",
            Data.Column1(i), Data.Column2(i), Data.Column3(i),
            Data.Column4(i), Data.Column5(i), Data.Column6(i));

        sb.CopyTo(0, buffer, 0, sb.Length);
        writer.Write(buffer, 0, sb.Length);
        writer.WriteLine();
    }
}

In this version, a StringBuilder and char[] array is created outside of the loop, and reused for each line in the .csv file. After a line is formed in the StringBuilder, we copy the result to the char[] array instead of converting it to string first.

At this stage, the biggest spender is calling AppendFormat. To pass data for the 6 columns to AppendFormat, C# generates code to allocate an Object[] array, and then boxes up three integers. Within AppendFormat implementation, Int32.ToString method is called to convert integers to string with invariant culture info. It will cost less memory and CPU to call ToString outselves:

static public void Version3()
{
    StringBuilder sb = new StringBuilder(512);
    char[] buffer = new char[512];

    CultureInfo info = CultureInfo.InvariantCulture;
                        
    for (int i = 0; i < count; i++)
    {
        sb.Clear();
        sb.AppendFormat(
            "\"{0}\",{1},{2},\"{3}\",\"{4}\",\"{5}\"",
            Data.Column1(i).ToString("x8", info),
            Data.Column2(i).ToString(info),
            Data.Column3(i).ToString(info),
            Data.Column4(i), Data.Column5(i), Data.Column6(i));

        sb.CopyTo(0, buffer, 0, sb.Length);
        writer.Write(buffer, 0, sb.Length);
        writer.WriteLine();
    }
}

If you profile the latest code again, you will find the three ToString calls consumes the most memory and CPU, it's time to replace them:

static public void Version4()
{
    StringBuilder sb = new StringBuilder(512);
    char[] buffer = new char[512];

    CultureInfo info = CultureInfo.InvariantCulture;

    for (int i = 0; i < count; i++)
    {
        sb.Clear();

        sb.Append('"');
        sb.AppendInt32(Data.Column1(i), 16, 8);
        sb.Append("\",");

        sb.AppendInt32(Data.Column2(i));
        sb.Append(',');

        sb.AppendInt32(Data.Column3(i));
        sb.Append(",\"");

        sb.Append(Data.Column4(i));
        sb.Append("\",\"");

        sb.Append(Data.Column5(i));
        sb.Append("\",\"");

        sb.Append(Data.Column6(i));
        sb.Append('"');

        sb.CopyTo(0, buffer, 0, sb.Length);
        writer.Write(buffer, 0, sb.Length);
        writer.WriteLine();
    }
}

If you wonder how much memory and CPU can these changes save us, here is the performance test result:

WriteLine.exe

       WriteLine x  1,000,000   1292.942 ms 161 gc,  1,829,516 bytes
           Write x  1,000,000    989.864 ms 122 gc,  2,527,544 bytes
   StringBuilder x  1,000,000    925.884 ms  84 gc,    985,392 bytes
        ToString x  1,000,000    778.161 ms  43 gc,    415,552 bytes
       AppendInt x  1,000,000    638.102 ms   0 gc,    423,744 bytes

When generating a .csv file of 1 million rows, the original version takes 1.292 seconds, causing 161 garbage collections, and the final heap has 1.829 mb allocations. Subsequent versions reduce memory allocations and CPU time at the same time. The final version finishes in 0.638 seconds with not a single garbage collection. This indicates that the final version does not allocate any managed memory in the big loop.

Here  are CPU sample events displayed in PerfView:

Total program run takes 5.218 seconds, the original version takes 1.36 seconds (25.2% of total time), the final version takes 0.673 seconds.

Here are the CLR memory allocation tick events displayed in PerfView:

Total program run allocates 1.296 Gb of memory. The original version allocates 511 mb memory, StringBuilder.ToString allocates 130 mb, TextWrite.WriteLine allocates 117 mb. The final version (Version4) is not even shown here. CLR memory allocation tick event is fired once for every 100kb memory allocation or when big objects are allocated. Version4 only allocates a few small objects before entering the big loop, not enough to fire an event.

Quite a few fancy solutions are provided:

1. Regex.Replace(myString, @"[^\x20-\xaf]+", "");
2. new string(myString.Where(c => (c >= 32) && (c <= 175)).ToArray());
3. string text = (from c in myString let i = (int) c where i < 32 && i > 175 select c) .Aggregate("", (current, c) => current + c);   

The fastest solution is filtering while walkng through the string and build result using StringBuilder. But there are still places this can be improved. So here would be my solution:

static unsafe string TrimRange(string str, char from, char to)
{
    int count = 0;

    for (int i = 0; i < str.Length; i++)
    {
        char ch = str[i];

        if ((ch >= from) && (ch <= to))
        {
            count++;
        }
    }

    if (count == 0)
        return String.Empty;

    if (count == str.Length)
        return str;

    char * result = stackalloc char[count];

    count = 0;

    for (int i = 0; i < str.Length; i++)
    {
        char ch = str[i];

        if ((ch >= from) && (ch <= to))
        {
            result[count ++] = ch;
        }
    }

    return new String(result, 0, count);
}

The idea is quite simple: allocate managed memory only when really need.

Program.cs (attached)

New features:

• endpath command to end a path with stroking
• closepath command to end a path with stroking and filling
• p command to store reference points
• r command to recall reference points
• Parsing and SVG generation seperated into two classes. We can later add generation of other formats.

Sample input (two properties):

S 893511 E 235.70
S 193826 E 28.68
endpath
S 614605 E 128.70
S 395224 E 72
S 340452 W 157.98
P0
N 534354 W 79.51
N 172709 w 87.74
n 652125 E 9.6
N 052600 E 112.75
closepath
R0
S 534354 E 75.40
S 063835 W 66.10
S 570654 E 64.04
N 535505 E 104.10
N 535505 E 52.90
N 382302 W 233.98
closepath

Sample output:

Program.cs

BEGINGING AT THE NORTHWEST CORNER OF SAID SOUTHWEST QUARTER OF THE SOUTHWEST QUARTER OF SECTION 9; THENCE SOUTH 89°35'11" EAST; 246.35 FEET ALONG THE NORTH LINE THEREOF; THENCE SOUTH 19°38'26" EAST, 36.08 FEET; ...

For each segment, the bearing part (e.g. SOUTH 89°35'11" EAST) specifies the direction of the line, which is followed by the length of the line. The relative degree of the line is specific using sexagesimal system (base-60, degree/minute/second). So 89°35'11" is really 89 + 35 / 60 + 11 / 3600 degrees. SOUTH 89°35'11" EAST means starting from south direction, turning 89.586 degrees to east.

Sometimes you can find a nicely drawn diagram (e.g. plat diagram, often as an TIFF image), but sometimes you just have the textual description and nothing else. The later is often the case in easement documents. Now the problem is how to convert such description into something we can visualize easily;

Here is a simple C# program which converts bearing and distance property description into SVG format, viewable using IE 9 (file attachment Program.cs).

Sample Input file:

S 893511 E 246.35
S 193826 E 36.08
S 614605 E 113.79
S 492357 W 87.36
N 843400 W 58
N 052600 E 112.75
N 193826 w 18.03
n 893511 w 239.2

SVG output generated by the program:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"  "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="640" height="480" viewBox="0 0 358.724254050077 146.439267225064" xmlns="https://www.w3.org/2000/svg" version="1.1">
<line x1="0" y1="0" x2="400" y2="0" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="0" y1="100" x2="400" y2="100" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="0" y1="200" x2="400" y2="200" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="0" y1="0" x2="0" y2="200" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="100" y1="0" x2="100" y2="200" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="200" y1="0" x2="200" y2="200" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="300" y1="0" x2="300" y2="200" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<line x1="400" y1="0" x2="400" y2="200" style="stroke:black;stroke-width:0.5;stroke-dasharray:1,1"/>
<path d="M 0 0
  l 246.343581111762 1.77835458583686
  l 12.1271482740708 33.9808574750359
  l 100.253524664245 53.8274548199679
  l -66.3291145282373 56.8526003442234
  l -57.7394086754221 -5.49187452629729
  l 10.6760147041382 -112.243419450928
  l -6.0602129540326 -16.9810105397699
  l -239.193767411948 -1.72674007279144
z" fill="yellow" fill-opacity="0.5" stroke="black" stroke-width="1" />
</svg>

SVG output rendered by IE9

Surprise: The SVG file generated can be imported directly by Microsoft Visio. You can even ungroup it, and then change line and fill properties.

Program.cs

Edsger W. Dijkstra's Three Golden Rules for Successful Scientific Research:

    011E100E push  10h
    011E1010 pop   eax
    011E1011 call  _chkstk (011E1810h)
    011E1016 mov   ecx,esp

My understanding is that _chkstk call is generatesd by C++ compiler when there are more than 4kb local variable allocation. But here the code is only allocating 16 bytes. This is important because _chkstk is not cheap:

011E1810  push        ecx
011E1811  lea         ecx, [esp+4]
011E1815  sub         ecx,eax  
011E1817  sbb         eax,eax  
011E1819  not         eax  
011E181B  and         ecx,eax  
011E181D  mov         eax,esp  
011E181F  and         eax,0FFFFF000h  
011E1824  cmp         ecx,eax  
011E1826  jb          cs20 (011E1832h)  
011E1828  mov         eax,ecx  
011E182A  pop         ecx  
011E182B  xchg        eax,esp  
011E182C  mov         eax,dword ptr [eax]  
011E182E  mov         dword ptr [esp],eax  
011E1831  ret  

 
After digging through layers of  macros, I finally found out that this _chkstk call is generated by an _alloca call for 16-byte of storage. Here is a repro case:
int _tmain(int argc, _TCHAR* argv[])
{
    RECT * pRect = (RECT *) _alloca(sizeof(RECT));
 
    pRect->left = 10;
    return pRect->left;
}
As the object is always needed, the fix is quite easy, just allocate on the stack together with other local variables (for free).