Подскажите пожалуйсто, как узнать сколько раз вызывался GC, т.е. сколько раз произошёл сбор мусора за время работы приложения?

Явно — никак.
Но можно предложить обходной манёвр. Например, можно создать специальный объект и ссылку на него никуда не поместить. При следующей сборке мусора у такого объекта вызовется финализатор (aka деструктор), в котором можно и произвести подсчёт количества сборок мусора. И сразу после этого — создать новый такой же объект, который "учтёт" следующую сборку мусора.
Примерно вот так:

public class GCCounter
{
    public static int Count = 0;
 
    ~GCCounter()
   {
      Count++;
      new GCCounter();
   }
}

А в начале программы (или там, откуда вы хотите начать подсчёт) просто создать этот объект:

new GCCounter();

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Ещё одно замечание.
Я не уверен до конца, но если компилятор окажется достаточно умным, он может удалить эти "бесцельные" создания объектов, заметив, что конструктор всё равно пустой. Бороться с этой оптимизацией можно несколькими способами. Самое очевидное — поместить ссылку на объект в локальную переменную:

  GCCounter c = new GCCounter();

Ведь эта переменная всё равно пропадёт при выходе из своей зоны видимости. Тем не менее, компилятор и эту переменную, скорее всего, удалит в целях оптимизации.
К счастью, именно для борьбы с оптимизацией в .NET существует специальный метод — GC.KeepAlive(). Пользоваться им в данном случае следует так:

  GC.KeepAlive( new GCCounter() );

Этот метод ничего не делает. Смысл его заключается именно (и только) в том, чтобы "обмануть" оптимизатор: раз оптимизатор видит, что ссылка на объект передаётся в какой-то метод, он не имеет права исключить из кода создание этого объекта. Поэтому теперь наша схема должна сработать как задумано.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, eBoy, Вы писали:

B>Подскажите пожалуйсто, как узнать сколько раз вызывался GC, т.е. сколько раз произошёл сбор мусора за время работы приложения?

Performance Monitor

Здравствуйте, Name, Вы писали:

N>Ещё одно замечание.
N>Я не уверен до конца, но если компилятор окажется достаточно умным, он может удалить эти "бесцельные" создания объектов, заметив, что конструктор всё равно пустой. Бороться с этой оптимизацией можно несколькими способами. Самое очевидное — поместить ссылку на объект в локальную переменную:

N>

  GCCounter c = new GCCounter();
N>

N>Ведь эта переменная всё равно пропадёт при выходе из своей зоны видимости. Тем не менее, компилятор и эту переменную, скорее всего, удалит в целях оптимизации.
N>К счастью, именно для борьбы с оптимизацией в .NET существует специальный метод — GC.KeepAlive(). Пользоваться им в данном случае следует так:

N>

  GC.KeepAlive( new GCCounter() );

N>Этот метод ничего не делает. Смысл его заключается именно (и только) в том, чтобы "обмануть" оптимизатор: раз оптимизатор видит, что ссылка на объект передаётся в какой-то метод, он не имеет права исключить из кода создание этого объекта. Поэтому теперь наша схема должна сработать как задумано.

A ne polucitsia li tak, sto budet scetatsia toka sbor musora v pokolenii 1? Ved esli objekt perezyviot sbor musora on peremestitsia v sledujuscee pokolenie.

Да, именно так и получится.
Я не претендовал на полное решение, хотел лишь изложить идею. Ту же идею можно использовать и для подсчёта сбора мусора во втором поколении (а также третьем, пятом и десятом, если они когда-нибудь появятся). Для этого надо просто завести два таких объекта, на первый из которых будет (где-то) существовать ссылка, а второй перед смертью будет эту ссылку удалять. Таким образом, первый объект переживёт первый сбор мусора, но погибнет во время второго.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение