Профилирование памяти с помощью вопросов DotTrace

Question

Я запустил dotTrace в своем приложении (с некоторыми проблемами).

IntPtr System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)

Void System.Windows.Forms.UnsafeNativeMethods.WaitMessage()

Это две основные функции, которые заняли около 94% времени приложения.

Поскольку я не знал, что это за две функции, я построчно просматривал свой код. Он работает плавно и эффективно до точки, где он просто висит. "NewFrm.Show ()".

newFrm содержит только текстовое поле. Чем больше файл, который я загружаю в текстовое поле (это программа-блокнот), тем дольше это занимает. Обычно это имеет смысл, но для файла размером 167 КБ требуется около 30 секунд.

Теперь я не уверен, что делать. Он работает невероятно медленно / перестает работать, когда вы загружаете текстовый файл и пытаетесь изменить размер окна, содержащего текстовый файл.

Тогда я понял, что это только трудно открыть текстовые файлы с длинной строкой шестнадцатеричного внутри (то есть) "XX-XX-XX-" и т. Д. С другими файлами аналогичного размера он борется с изменением размера, но открывается внутри пара секунд.

Это как-то связано со свойствами текстового поля? Я установил его на многострочное и установил максимальное количество символов 0 (так неограниченно).

Как мне решить эту проблему? Есть ли какой-нибудь способ узнать, что вызывается в этих функциях?

Answer 1

Это нормально для профилировщика, чтобы показать, что большая часть выполнения происходит в этих вызовах Windows API. CallWindowProc () запускает обработчик сообщений по умолчанию для элемента управления, вы измеряете, сколько времени требуется встроенному в Windows элементу управления для редактирования, встроенному в Windows, для обработки вашего текстового файла. WaitMessage () вращается, ожидая сообщения от Windows о том, что произошло что-то интересное. Это затрудняет профилирование кода GUI, вам нужно поднять код, который вы написали, в программу стиля модульного теста. Это не практично, вы не написали код, который занимает все циклы процессора.

Ваша проблема в том, что TextBox не очень хороший текстовый редактор. Он не имеет каких-либо оптимизаций, которые вы найдете в полном редакторе. Обязательно отключите свойство WordWrap, это особенно дорого. И убедитесь, что TextBox не заполняет строку за строкой из файла, это очень медленно, поскольку нативный элемент управления постоянно должен перераспределять свой буфер. Используйте File.ReadAllText () или используйте StringBuilder, затем присвойте Text.

Что-то вроде открытого исходного кода ScintillaNET делает работу намного лучше.