я профилированный мое заявление и обнаружил, что не мои функции вызывают задержку я вижу, но WinForm functions-, как я могу это исправить, для explantion посмотреть:Как я могу оптимизировать производительность моего приложения на основе профиля?
и это результат профилирования:
http://www.megaupload.com/?d=2YUQWVQ6 (вывезенный в формате HTML)
Вы не можете исправить это.
Каркас призывающий к DispatchMessage function выставленному API Windows, который используется для отправки сообщения, полученное с помощью вызова функции GetMessage к оконной процедуре для конкретного окна.
«Медленная» часть - это сама ОС. Когда это станет вашим узким местом, ваше приложение будет достаточно оптимизировано, и вы больше ничего не сможете сделать.
Кроме того, эти результаты не обязательно говорят вам, что эта функция slow. Скорее, они говорят вам, что он часто получает («Hit Count»). Идея состоит в том, что функции, получившие много имен, являются «горячими точками» в вашем коде, и стоит потратить некоторое дополнительное время на оптимизацию их реализации (больше ударов для вашего доллара). В этом случае, однако, эта функция называется много, потому что именно Windows обрабатывает сообщения для вашего приложения. В мире неуправляемого кода и собственного API Windows сообщения похожи на события, которые вы используете в коде .NET. Поскольку событие должно быть поднято для чего-либо интересного, функция, которая отвечает за вызов или отправку этих событий (сообщений), неизбежно получит много имен.
Я вижу большое спасибо, так или иначе, но я могу сделать это лучше? каждое событие отправляет сообщение? –
@Blue Gene: Мне нужно будет увидеть больше кода, чтобы дать вам более конкретные подсказки об оптимизации. Но я серьезно сомневаюсь, что вы можете сделать что-то еще. Результаты профиля, которые вы получаете, бесполезны - они сообщают вам, что внутренний код .NET Framework медленный, или сама Windows медленная. Поскольку вы не пишете этот код, вы не можете его оптимизировать. Нет, но biggie, поскольку каждый другой программист должен работать в тех же самых ограничениях. Вряд ли ваше приложение будет медленнее, чем у них. –
Приложения Windows обычно содержат петлю верхнего уровня, где они ждут внешних событий, таких как движения/клики мыши и хиты клавиатуры, или события, созданные внутри. Когда происходит событие, он вызывает соответствующий обработчик, который может сделать немного или много. Обычно он проходит довольно обширное и глубокое дерево вызовов, но если он быстро заканчивается, он просто возвращается к ожиданию.
Приложение, которое, как представляется, хорошо работает, проводит большую часть времени настенных часов, ожидая следующего внешнего события.
Приложение, которое, как представляется, плохо работает, тратит большую часть времени на посещение деревьев вызовов в ответ на события.
Способ повышения его производительности - выявить узкие места и удалить их. Узкие места почти всегда состоят из вызовов функций в дереве вызовов, в вашем коде, которые вы не знали, были дорогими. Части дерева вызовов, которые не входят в ваш код, - это то, о чем вы ничего не можете сделать, но если вы можете избежать их вызова, у вас есть возможность получить ускорение.
Как если бы вы были менеджером, пытающимся выяснить, тратят ли ваши сотрудники время, вы можете просто отказаться от участия в обсуждении и посмотреть, что они делают. В программном обеспечении, this is how you can do that.
Будьте осторожны с профайлерами, которые путают вас такими вещами, как: 1) рассказывая вам о «времени на себя» подпрограмм, 2) сообщая вам, сколько раз функция вызывается, 3) дает вам массивный, но в основном нерелевантный график или таблицу, или 4) много интересных, но не всегда релевантных подсказок, таких как промахи кеша и переключатели потоков.
Нахождение узких мест очень просто, потому что, если они маленькие, они не являются узкими местами, и если они большие, то в то время, когда они тратят впустую, они находятся в стеке, просто ожидая, что вы заметите. Here's more on that subject.
@Mike, но профайлер (RedGates Ants) показал, что большую часть времени тратится на часть дерева вызовов, которая не является моим кодом на картинке. –
@Blue: Кажется, я не могу получить картину. (Он попадает в какую-то большую вещь для скачивания.) Неважно. Когда я слышу «большую часть времени, проведенного в ...», мои уши оживляют, потому что это звучит как основная путаница профайлера. Самостоятельное время? Пожалуйста, проигнорируйте это - это бесполезно. Включая время? Настенное или процессорное время? Время стены - это то, что вам нужно. По функции или по строке? По линии - это то, что вам нужно. Хит-счет - бесполезный. Миллисекунды или проценты? Процент - это то, что вам нужно. То, что вы ищете, - это строки в вашем коде, которые находятся в стеке (то есть активны), на высокий процент времени на стене. Есть какие-то из них? –
Это похоже на общее введение в оптимизацию на основе профиля, а не на ответ на конкретный вопрос. Возможно, это моя вина, учитывая, как я перефразировал заголовок вопроса. Проблема здесь в том, что искатель хочет знать, как оптимизировать вызовы API, сделанные внутренней инфраструктурой. Это не реально. –
Что делает ваша программа в целом? Является ли пользовательский интерфейс чем-то странным, вы заметили замедленность при его использовании? – BrandonAGr