Чи слід компілювати версії версій з інформацією про налагодження як "повні" або "лише для pdb"?

114

У Visual Studio 2010 для проекту C #, якщо ви перейдете до Властивості проекту> Збірка> Додатково> Інформація про налагодження, у вас є три варіанти: жоден, повний або лише pdb. Виходячи з відповіді на це питання , я вважаю, що я розумію деякі відмінності між повним і лише для pdb. Однак що більше підходить для складання релізу? Якщо я використовую "full", чи будуть наслідки для продуктивності? Якщо я використовую лише "pdb", чи важче буде налагодити виробничі проблеми?

Яка різниця між "full" та "pdbonly"? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

— RationalGeek
джерело

Pdb-тільки або жоден, завжди для версій версій.

— леппі

13

@leppie Дякую, але я шукаю певне виправдання цієї позиції.

— RationalGeek

Пов'язаний питання: stackoverflow.com/questions/1270986 / ...

— janv8000

Це чудово, якщо немає впливу на продуктивність. А як щодо впливу пам'яті? Якщо я створюю екземпляр StackTrace і запитую інформацію про файл, він повинен надходити з даних символу pdb. Чи всі символи завантажуються в пам'ять при застосуванні? Яке приблизне використання пам'яті для цього? (наприклад, відсоток накладних витрат щодо розміру коду.)

— yoyo

90

Я б будував з pdb-only. Ви не зможете приєднати налагоджувач до випущеного продукту, але якщо ви отримаєте дамп аварійного завершення, ви можете скористатися Visual Studio або WinDBG для вивчення слідів стека та скидів пам’яті під час аварії.

Якщо ви скористаєтесь, fullа не скористаєтеся pdb-only, ви отримаєте ті самі переваги, за винятком того, що виконуваний файл можна приєднати безпосередньо до налагоджувача. Вам потрібно буде визначити, чи розумно це з огляду на ваш продукт та клієнтів.

Не забудьте зберегти файли PDB кудись, щоб ви могли посилатися на них, коли надходить звіт про збій. Якщо ви можете встановити сервер символів для зберігання цих символів налагодження, тим краще, тим краще.

Якщо ви вирішите будувати з ним none, ви не будете звертатися до уваги, коли в полі буде аварія. Ви не зможете провести будь-який вид фактичного дослідження аварії, що може сильно утруднити вашу здатність відстежувати проблему.

Примітка про продуктивність:

І Джон Роббінс, і Ерік Ліпперт написали повідомлення в блозі про /debugпрапор, і вони обоє вказують, що цей параметр має нульовий вплив на продуктивність . Існує окремий /optimizeпрапор, який диктує, чи повинен компілятор проводити оптимізацію.

— Метт Діллард
джерело

7

@Matt, стаття MSDN про перемикач / debug явно попереджає про вплив на продуктивність використання налаштування "full":

If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.

— Allon Guralnek

3

@Matt: Якщо "full" не має недоліків порівняно з "samo pdb", але має лише переваги, чому "pdb-only" навіть існує? Чи є якась причина використовувати його над «повним»? Також слід додати виправлення до статті MSDN у розділі "Вміст спільноти".

— Аллон Гуралнек

9

Цитата @AllonGuralnek з пов'язаної статті Джона Роббінса: Справжня причина: історія. Ще в .NET 1.0 були відмінності, але в .NET 2.0 немає. Схоже, що .NET 4.0 піде за тією ж схемою. Після подвійної перевірки з командою налагодження CLR взагалі немає різниці.

— bentayloruk

5

Це неправда. Ви можете створювати лише за допомогою pdb та все ж приєднувати налагоджувач. Я просто це зробив, щоб бути впевненим.

— Марк

2

"Я б будував лише за допомогою pdb. Ви не зможете приєднати налагоджувач до випущеного продукту" Яке тут ваше джерело інформації? Як і Марк, і я зазначили, це здається не правильним.

— ПАМ'ЯТ

66

ПОПЕРЕДЖЕННЯ документація MSDN для перемикання / налагодження (у Visual Studio це інформація про налагодження), здається, застаріла! Це те, що є невірним

Якщо ви використовуєте / debug: full , майте на увазі, що деякий вплив на швидкість та розмір коду, оптимізованого JIT, і невеликий вплив на якість коду з / debug: full . Ми рекомендуємо / налагоджувати: pdbonly або відсутність PDB для створення коду випуску.

Одна різниця між / debug: pdbonly та / debug: full полягає в тому, що з / debug: full компілятор випускає a DebuggableAttribute, який використовується для того, щоб повідомити компілятору JIT, що інформація про налагодження доступна.

Тоді, що зараз правда?

Тільки для Pdb - До .NET 2.0 він допомагав розслідувати викиди крапів із випущеного продукту (машини клієнта). Але це не дозволило приєднати налагоджувач. Це не так .NET 2.0. Це точно так само, як і Full .
Повна - Це допомагає нам досліджувати демпінг-збої, а також дозволяє нам приєднати налагоджувач для випуску збірки. Але на відміну від MSDN згадує, це не впливає на продуктивність (оскільки .NET 2.0). Це робить точно так само, як і лише Pdb .

Якщо вони точно такі, чому ми маємо ці варіанти? Джон Роббінс (бог налагодження вікон) з’ясував, що вони існують з історичних причин.

Ще в .NET 1.0 були відмінності, але в .NET 2.0 немає. Схоже, що .NET 4.0 піде за тією ж схемою. Після подвійної перевірки з командою налагодження CLR взагалі немає різниці.

Те, що контролює, чи робить JITter збірку налагодження, - це перемикач / оптимізувати. <…>

Суть полягає в тому, що ви хочете скласти свої версії версій за допомогою / optimize + та будь-якого з / dbug-комутаторів, щоб ви могли налагоджувати вихідний код.

потім він продовжує доводити це.

Зараз оптимізація є частиною окремого перемикача /optimize(у візуальній студії це називається Optimize code).

Коротше кажучи, незалежно від налаштування DebugInfo лише для pdb або full, ми матимемо однакові результати. Рекомендація - не уникати жодного, оскільки це позбавить вас можливості аналізу відвалів випущеного продукту або приєднання налагоджувача.

— рпаттабі
джерело

3

Фантастична відповідь! Мої власні дослідження (порівняння створених файлів) показують однакові результати.

— ПАМ'ЯТ

@rpattabi Чи можете ви вказати посилання, що pdbonly і full є однаковими? Настає 2019 рік, і документація все ще вказує на те, що вони різні та повні, буде знижена продуктивність. І VS2019 створює проект з Releaseналагодженням конфігурації за замовчуванням, встановленим на pdbonly.

— Джо

@joe Внизу документації MSDN йде дискусія msdn.microsoft.com/en-us/library/8cw0bt21.aspx . Погляньте на це. Один довідник вказав на github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/… для отримання актуальної інформації, де pdbonly та full згадуються як однакові. (FYI. Я більше не використовую windows або VS. Тому я не слідкував за тим, що там відбувається. Але, як я переглянув, інформація у моїй відповіді як і раніше є актуальною, і MSDN doc досі невірна.)

— rpattabi

16

Ви хочете лише PDB, але ви не хочете надавати файли PDB користувачам. Однак, маючи їх для себе, поряд із бінарними файлами, ви можете завантажувати аварійні звалища у відладчик, як WinDbg, і бачити, де насправді програма не вийшла. Це може бути досить корисно, коли ваш код виходить з ладу на машині, до якої ви не маєте доступу.

Повна налагодження додає атрибут [Debuggable] до вашого коду. Це має величезний вплив на швидкість. Наприклад, деякі оптимізації циклу можуть бути відключені, щоб полегшити один крок. Крім того, це має невеликий вплив на процес JIT, оскільки він призводить до стеження.

— удар
джерело

Має сенс. Я взагалі не поширюю DLL серед користувачів - це програма ASP.NET. Але чи можете ви покращити свою відповідь та обґрунтувати, чому вам слід пройти лише з "pdb" та "full"? Це проблема продуктивності?

— RationalGeek

@jkohlhepp: Я хотів би додати, що цей випуск налагодження випуску є трохи складним, оскільки ви втратите деяку інформацію (через JIT). Майже завжди ви не зможете побачити значення аргументів методу. Щоб вирішити це, ви можете тимчасово відключити оптимізацію JIT, використовуючи це .

— Іліан Пінзон

Дякую удар, і дякую Іліану Пінзону за додаткову інформацію. Я знаю, ви не можете отримати ідеальну налагодження з кодом випуску, але мати PDB - це краще, ніж нічого.

— RationalGeek

Використання «повної» настройки зовсім НЕ мають впливу на продуктивність. Він просто дозволяє приєднувати налагоджувач до запущеного процесу.

— Метт Діллард

1

Добре запитання про MSDN Matt, msdn.microsoft.com/en-us/library/8cw0bt21 , чекаючи відповіді сам.

— Люк Хаттон

4

Я в процесі написання необробленого обробника винятків, і слід стека включає номер рядка, коли використовується лише pdb, інакше я просто отримую назву Sub / Function, коли вибираю None.

Якщо я не поширюю .pdb, я не отримую номер рядка в стеці стека навіть при збірці, призначеній лише для pdb.

Отже, я поширюю (розгортання XCOPY в локальній мережі) pdb разом з exe з мого додатка VB.

— Рейцман
джерело