Как найти слабые места в проекте?

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

1) Мне требуется оптимизировать код, но хочется начать с самых проблемных мест, которые дадут самый ощутимый результат. Возник вопрос, как отследить слабые места кода? Какие функции вызываются чаще всего и как долго они работают? Я более чем уверен, что имеются возможность отследить это в автоматическом режиме. Что можно использовать? Для работы с проектом используется Visual Studio 2008. В ней я пытался использовать встроенные возможности анализа, но в результате получил отсылки к внешним библиотекам, которые мне совершенно не интересны. Так же, мне этот анализ показался не достаточно гибким (может я плохо в нем разбираюсь?). Может кто-нибудь может порекомендовать мне что-нибудь еще? Хотя бы ключевые слова для поиска в Google? )

2) В коде повсеместно используются массивы и указатели. В частности, почти везде используются указатели на массив char (перевести весь проект на более безопасные методы хранения данных по некоторым причинам не представляется возможным). Я предполагаю, что в проекте систематически происходят выходы за пределы массива. Отследить подобные моменты очень сложно, особенно во время пересчета, когда пересчет длиться более суток, а потенциальных мест возникновения ошибки, без преувеличения, насчитывается более тысячи. Я нашел инструменты, которые встраиваются в Visual Studio и находят подобные места в ходе работы проекта, но они платные и найти их в свободном доступе невозможно. Это Insure++ и BoundsChecker. Нашел через эту статью. Возможно, кто-нибудь знает бесплатные аналоги или те, которые можно найти в свободном доступе?!

Заранее благодарен за любую помощь в данных вопросах )

0

Для выявления проблемных мест с точки зрения производительности есть специальный инструмент - профилировщик, profiler. Я в свое время пользовал Intel VTune. Правда, он платный.

"Я нашел инструменты, которые встраиваются в Visual Studio и находят подобные места в ходе работы проекта, но они платные и найти их в свободном доступе невозможно." -
и что? Ну значит, надо выходить на руководство с обоснованием необходимости купить данные инструменты. Если "вдруг" окажется, что руководству это фиолетово, то тебе - тем более. Не стоит пытаться быть святее Папы римского. Будешь искать баг не два часа, а два месяца, а на все вопросы руководства "а почему так долго?" отсылай их к необходимости приобретения адекватных инструментов.

0

1) тут не особо подскажу)

2) вот так сделайте:
включите в настройках проекта:

Confg prorer:
- C++/CodeGen/ св-во Buffer security check = /GS
- Linker/advanced:
не помню св-ва, найдете, надо выстовить значения(там вроде по умолчанию стоят) /SAFESEH /NXCOMPAT /DYNAMICBASE.
- Code Analys /analyze Visual Studio;

покажет варнинги на переполнение буфера и на парочку других, их все по хорошему надо устранить( примерно вот этот диапазон (C6001-C6535)), конечно не все опасные места покажет, но всякие небезопасные функции типа strcpy, memcpy и т.п. должен отобразить.

вообще про безоспасность и переполнения буфера хватает нюансов

у нас на работе сча по безопасности загнались, теперь еще требует использовать sal.

0

Ну и еще бы я посоветовал выделить в VCS отдельную ветку и потихоньку начинать рефакторить проект.... Иначе дальше будет только хуже.

0

CheshireCat, профилировщик - это как-раз то, что нужно. Буду изучать. Спасибо!

А по поводу того, что нужно убедить начальство купить необходимый инструмент, это не всегда так просто, как кажется. Им нужно сперва увидеть результат, а уже потом они будут готовы дать деньги. Буду договариваться с разработчиками на предоставления демонстрационной версии. Вроде бы у них это возможно.

Aloir, дело в том, что весь проект построен на strcpy и memcpy, а так же на прочих опасных функциях и методах программирования. Искать подобные места не требуется, нужно просто открыть исходный код и любоваться. Самое интересное, что проект относительно стабилен. Очень хорошо в анализе статического кода помогла PVS-Studio (она работает эффективнее встроенных механизмов самой Visual Studio). Все найденные ей ошибки были исправлены, многое было переписано.

0

Еще бы я посоветовал попытаться осмыслить алгоритм и оптимизировать именно его. Высокоуровневая (алгоритмическая) оптимизация дает выигрыш сильно больше, чем низкоуровневая (на уровне функций memcpy/strcpy, к примеру).
В моей практике много лет назад был случай, когда надо было ускорить программу раза в полтора, чтобы обойти продукт конкурентов. Увы, никакие низкоуровневые оптимизации, даже копание на уровне ассемблерного кода, не могли ускорить код больше, чем на несколько процентов. Зато когда я переосмыслил алгоритм и переписал его целиком, программу "взлетела" - стала работать шустрее примерно в 3 раза!

0

Сообщение от g0liath CheshireCat, профилировщик - это как-раз то, что нужно. Буду изучать. Спасибо! А по поводу того, что нужно убедить начальство купить необходимый инструмент, это не всегда так просто, как кажется. Им нужно сперва увидеть результат, а уже потом они будут готовы дать деньги. Буду договариваться с разработчиками на предоставления демонстрационной версии. Вроде бы у них это возможно. Aloir, дело в том, что весь проект построен на strcpy и memcpy, а так же на прочих опасных функциях и методах программирования. Искать подобные места не требуется, нужно просто открыть исходный код и любоваться. Самое интересное, что проект относительно стабилен. Очень хорошо в анализе статического кода помогла PVS-Studio (она работает эффективнее встроенных механизмов самой Visual Studio). Все найденные ей ошибки были исправлены, многое было переписано.

стабилен) мб потому что никто не задавался возможностью взлома?)
как выше писали, + к рефакторингу и оптимизация. если в дальнейшем вам будет важна безопасность стоит задуматься.

пс: многие проблемы решаются путем замены например strcpy на strcpy_s, но с указателями там засада будет.. надо будет передовать все-таки размер буфера

0