Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
menu search
person
Welcome To Ask or Share your Answers For Others

Categories

I am deploying ASP.NET and Web Service solutions to IIS for a development server. It looks like the last person that did this job deployed all the .pdb files too. I asked about it, and was told that they "provide better stack trace info in the logs" if they are left on the server.

Is there any truth to this? I've always left them behind, never deploying them to anywhere other than my local machine.

For an internal development IIS server (not production, not accessible to the outside world) is there any reason to or not to deploy the .pdb files? Is there anything bad that could happen? Do they really provide any benefit?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
334 views
Welcome To Ask or Share your Answers For Others

1 Answer

I always figured the .pdb files were only used by the debugger. If the runtime always checks for them for debug info, that should mean slower execution when throwing an exception, because it has to read the .pdb, right?

So I made a quick test:

using System;
using System.Text;

namespace PdbSpeedTest
{
    class Program
    {
        static void Main(string[] args)
        {
            DateTime start = DateTime.Now;
            try
            {
                Program p = new Program();
                p.Looper(0);
            }
            catch (NotImplementedException e)
            {
                Console.WriteLine(e.StackTrace);
            }
            TimeSpan span = DateTime.Now - start;
            Console.WriteLine(span.TotalMilliseconds.ToString());
        }

        internal void Looper(int x)
        {
            try
            {
                if (x < 100)
                    Looper(x + 1);
                else
                    throw new NotImplementedException("blah!");
            }
            catch (NotImplementedException e)
            {
                throw new NotImplementedException("blah!", e);
            }
        }
    }
}

This just recurses 100 levels deep and throws an exception. Now for the runtime results:

Running as a debug build with the .pdb in the same folder:

C:WorkPdbSpeedTestinDebug>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x) in C:WorkPdbSpeedTestProgram.cs:line 37
   at PdbSpeedTest.Program.Main(String[] args) in C:WorkPdbSpeedTestProgram.cs:line 16
31.2504

Running as a debug build without the .pdb:

C:WorkPdbSpeedTestinDebug>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x)
   at PdbSpeedTest.Program.Main(String[] args)
15.6252

Running as a release build with the .pdb:

C:WorkPdbSpeedTestinRelease>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x) in C:WorkPdbSpeedTestProgram.cs:line 37
   at PdbSpeedTest.Program.Main(String[] args) in C:WorkPdbSpeedTestProgram.cs:line 16
31.2504

Running as a release build without the .pdb:

C:WorkPdbSpeedTestinRelease>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x)
   at PdbSpeedTest.Program.Main(String[] args)
15.6252

These were run from a regular old command prompt, not inside Visual Studio. So the .pdb definitely does add stack trace info, and slows down the exception handling. Very interesting!


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
...