Is a variable stored in Session deserialized once or multiple times throughout a page lifecycle?

Question

I would like to wrap Session variables in a manner similar to that discussed on CodeProject.

public static class WebSession
{
  private const string CurrentUserKey = "CurrentUser";

  private static HttpSessionState Session
  {
    get { return HttpContext.Current.Session; }
  }

  public static bool Exists
  {
    get { return Session != null; }
  }

  public static User CurrentUser
  {
    get { return Session[CurrentUserKey] as User; }
    set { Session[CurrentUserKey] = value; }
  }
}

Here is my question: if I have to access CurrentUser multiple times in the same page, would I get a performance improvement by assigning it to a local variable instead of accessing the wrapping property? Or does the HttpSessionState make sure the object is only deserialized once per request, so that subsequent calls in the same http request don't cost any more?

Thanks, Aaron

Answer 1

some good articles to read

http://msdn.microsoft.com/en-us/library/aa479041.aspx

http://msdn.microsoft.com/en-us/magazine/cc163730.aspx#S5

Answer 2

There is an in-memory copy of your Session state on each request. Therefore the only cost that you would be saving by locally copying a session variable is that of the cast from Object to your type. The in-memory copy is then added to Session at the end of the request.

Whether or not Session is serialized and deserialized on a page depends on what Session Provider you choose. For In-proc Session State, no serialization occurs. For Session Servers the object must be serialized first.

Answer 3

I did some work pulling apart session recently, and from what I could see, the entire state object is deserialized once and once only per request. Of course, it is easy enough to check - just fetch it out twice and check ReferenceEquals.

Of course, placing the value in a field between uses would save some "lookup" time, but you should only pay the deserialization cost once.

If you really wanted to be sure, you could also double-check this by implementing ISerializable and logging serialize / deserialize calls.

Answer 4

There is an in-memory copy. You get negligible performance improvement from caching the value; it would save only a Dictionary lookup, which will be too fast to notice unless you're doing it a zillion times per page load.

Also important to note is that for a given key, each retrieval returns a reference to the same instance, and Session keeps a reference too. That means, if you retrieve an object from Session and modify it, you need not call the setter again to re-serialize it.

I just asked a question about this same thing: http://stackoverflow.com/questions/2141060