У нас есть приложение .NET, которое наши клиенты считают слишком большим для массового развертывания, и мы хотели бы понять, что способствует нашему пространству памяти, и можно ли сделать что-то лучше, не отказываясь от .NET и wpf.
Мы заинтересованы в улучшении как общего размера, так и личного рабочего набора (pws). В этом вопросе я просто хочу посмотреть на pws. VMMap обычно сообщает pws 105 мб. Из этого 11mb изображение, 31mb - куча, 52 mb - управляемая куча, 7 mb - личные данные, а остальное - стек, таблица страниц и т.д.
Крупнейшим призом здесь является управляемая куча. Мы можем составлять около 8 мб управляемой кучи непосредственно внутри нашего собственного кода, т.е. Объектов и окон, которые мы создаем и управляем. Остальные - предположительно .NET-объекты, созданные элементами используемой структуры.
Что мы хотели бы сделать, так это определить, какой элемент учетной записи фреймворка для какой части этого использования и, возможно, перестроить нашу систему, чтобы избежать их использования там, где это возможно. Может ли кто-нибудь предложить, как это исследование может быть сделано?
Дальнейшие разъяснения:
Я использовал ряд инструментов до сих пор, включая отличные профили ANTS и WinDbg с SOS, и они позволяют мне видеть объекты в управляемой куче, но для настоящего интереса здесь нет "Что?", но 'Зачем?' В идеале я хотел бы сказать: "Ну, здесь создано 10 мб объектов, потому что мы используем WCF. Если мы напишем наш собственный родной транспорт, мы сможем сэкономить 8 МБ, что с риском x и рисками для развития".
Выполнение gcroot на 300 000 + объектов невозможно.
