ASP.NET Response.WriteFile

Response.WriteFile handles binary data from a file. With WriteFile, we write a binary file—such as a PNG—to the Response buffer. It affects performance because the disk is accessed. This method is useful but has its drawbacks.

This C# article uses the Response.WriteFile method in ASP.NET. This method outputs a file to the page.

Example

First here we see that the Response.WriteFile method directly inserts the bytes of another file into your ASPX page. Here is the "before" code in which I inserted a PNG image into the ASPX file, which is displayed as a graphic in the browser.

Class that calls Response.WriteFile [C#]

using System;
using System.Web;
using System.Web.UI;
using System.IO;
using System.Diagnostics;

public partial class C_Default : Page
{
    protected override void OnLoad(EventArgs e)
    {
	//
	// Here we always give visitors the image.
	//
	WriteData();
	base.OnLoad(e);
    }

    private void WriteData()
    {
	Response.ContentType = "image/png";
	Response.WriteFile("Logo-Pale-Fireworks.png", true);
    }
}

Description. The above code always is run when the user loads the Default.aspx page. There is a file called "Logo-Pale-Fireworks.png" that is in the same directory.

Result: It shows users the PNG image. When the user's browser accesses Default.aspx above, it shows the Logo-Pale-Fireworks.png image.

Performance

In my testing, that approach is many times slower that using a custom C# byte[] cache. For some reason, the file system cache is easily defeated. This problem would likely still be present on the deployment installation.

Byte array cache

Here we see that you can just put the image's bytes into an array and store it in a static class. I felt the overhead of the C# code might outweigh the benefits here, but I was wrong. Using the byte[] cache here can ensure that the cache will be hit.

Class that writes byte array [C#]

using System;
using System.Web;
using System.Web.UI;
using System.IO;
using System.Diagnostics;

public partial class C_Default : Page
{
    protected override void OnLoad(EventArgs e)
    {
	//
	// Always give visitors the image
	//
	WriteData();
	base.OnLoad(e);
    }

    private void WriteData()
    {
	Response.ContentType = "image/png";
	Response.BinaryWrite(SiteData.Logo);
    }
}

Note. In the above code block, you will see the line Response.BinaryWrite(SiteData.Logo);. This is accessing the static property containing the bytes of the logo named "Logo-Pale-Fireworks.png"—here's that code.

Class that stores byte cache [C#]

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.IO;

public static class SiteData
{
    public static byte[] Logo
    {
	get
	{
	    return _logoBytes;
	}
    }

    static byte[] _logoBytes;

    static SiteData()
    {
	//
	// Caching the file this way is much faster than using WriteFile.
	//
	_logoBytes = File.ReadAllBytes(HttpContext.Current.Server.MapPath(
	    "~/C/Logo-Pale-Fireworks.png"));

    }
}

Tip: I put the above code in a new file in the App_Code folder. It uses a static constructor, which means it will only run once, usually lazily. Look at how the code is more complicated.

Is the static class faster?

Yes—quite a lot faster for repeated usages. Even in ideal conditions on the server, the first approach, which used WriteFile, will be slower because the file may not be in the file system cache. The second approach guarantees the file will be in memory.

Performance. There is a really obvious performance improvement by manually caching bytes. The above code blocks were executed 1000 times each, with the response buffer being cleared with Response.Clear() each iteration.

Benchmark results

Response.WriteFile usage:           10.680 s
Byte[] cache, Response.BinaryWrite:  0.094 s

Summary

We saw the Response.WriteFile method in ASP.NET using the C# language. Don't rely on file system caches for optimal performance. Use Cache objects or static classes to ensure a static resource is resident in memory. My experience with ASP.NET is that creating custom C# code is often far better for performance than using ASP.NET methods such as Response.WriteFile.