Помогите найти утечку с помощью Remote Performance Monitor

Question

Я пытаюсь найти источник утечки памяти в приложении Compact Framework с помощью Remote Performance Monitor. Мне удалось удалить несколько небольших объектов, связанных с кистями и другими графическими объектами, но я до сих пор не имею четкого представления о том, что вызывает основную проблему.

На данный момент единственными объектами, которые, кажется, никогда не возвращаются к исходному счету, являются объекты System.String. Я считаю, что это очень странно, так как я думал, что для того, чтобы эти объекты оставались неповрежденными, объекты, которые их содержат, также должны были остаться, и все же никакие другие типы объектов, похоже, не увеличиваются вместе с System.Strings.

Я пытаюсь выяснить, какие новые объекты String остаются после того, как приложение вернется в исходное состояние (например, экран входа в систему). Проблема в том, что изначально приложение загружается с примерно 2200 строковыми объектами, а затем после процесса «X» увеличивается еще 70 или около того, которые никогда не собираются. Я не знаю, как идентифицировать эти 70 новых объектов, чтобы выяснить, кто держится за них и внести соответствующие исправления.

Есть ли у кого-нибудь опыт, в котором строки не собирались? Есть ли способ отделить новые объекты, созданные во время процесса «X», от тех, которые изначально требовались приложением, чтобы я мог знать, что происходит утечка? Любой совет будет принят во внимание.

Благодаря

** UPDATE

Хорошо ... есть что-то очень странное происходит. Я начинаю сомневаться, есть ли утечка вообще.

Предположим, что я делаю снимок памяти на экране входа в систему, который является исходной отправной точкой приложения. Представьте себе, что в этой памяти на данный момент имеется 1000 строковых объектов. Теперь, если я вхожу в систему и выбираю вариант из меню, я сделаю снимок после загрузки нового экрана. Предположим, что загрузка этой формы увеличивает количество строк, например, 50 объектов. Когда я выхожу из системы и снова делаю снимок на экране входа в систему, только 25 из этих объектов были собраны, остальные останутся в памяти с тех пор.

Странно, что если я продолжу повторять этот процесс, дальнейшие строковые объекты не будут накапливаться. Вместо того, чтобы число строк увеличилось на 50, в этот момент будет добавлено только 25, и те же самые 25 будут собраны, как только я вернусь к экрану входа. Я думаю, что если бы это была настоящая утечка, то каждый раз, когда я открывал этот экран, количество строк увеличивалось бы постоянно на 25, но это происходит только в первый раз.

Это происходит со мной на каждом новом экране, который я открываю. Сначала происходит небольшое постоянное увеличение общего количества строк, но как только я загрузил этот конкретный экран, любое увеличение количества строк во время его выполнения будет собрано, как только я вернусь к экрану входа.

Все это привело меня к мысли, что, возможно, эти строки являются частью внутренней работы CLR или что-то в этом роде. Это может быть какое-то кэширование, выполняемое средой выполнения? Возможно, он хранит мои строковые константы для более быстрой загрузки? Что-то вроде того? Надеюсь, это не слишком смущает.

Answer 1

Если вы используете CF 3.5, используйте the CLR Profiler вместо RPM. Он покажет вам все объекты и корни, которые породили их. Это позволит вам вернуться к корневому дереву, чтобы выяснить, где они были выделены.

EDIT

Так вы говорите, что вы на самом деле не получают OOMS или любое aberrent поведение? Похоже, вы пытаетесь оптимизировать, когда это не нужно. Эта строка - это, вероятно, такие вещи, как титры форм и т. Д., Которые создает JITTER и собираются, если/когда объекты будут собраны. Однако то, что они есть, действительно не очень важно, если вы на самом деле не видите проблемы с памятью.