Помогите найти утечку с помощью Remote Performance Monitor - PullRequest
1 голос
/ 24 ноября 2010

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

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

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

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

Спасибо

** ОБНОВЛЕНИЕ

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

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

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

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

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

1 Ответ

0 голосов
/ 24 ноября 2010

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

EDIT

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

...