Russian Qt Forum

Всем привет,
 
нужно протестировать курсовой на утечку памяти. С профилированием до сих пор не сталкивался. Посоветуйте, чем лучше пользоваться?

VTune
CodeAnalyst
AQtime
Valgrind

Что из этого больше подходит?

Valgrind хвалят.
И не путай профилирование с поиском утечки памяти. Профилирование - для сбора статистики. А поиск утечки это бядаа :)

PS в 2 проектах, в которых я программно пытался найти утечку - не получилось. :)

Dr.Memory мне помогал как-то на винде.

Спасибо за советы.   :)

А вопрос о профилировании тоже не маловажный.
Я знаю в кодеблоке есть интерфейс к профилировщику жпрофу.
Было бы полезно закинуть такой же и в креатор.

в VS2008+ имеется встроенный профилировщик. Точнее модуль, идущий в комплекте :)

Достаточно хороший для нахождения тормозящей функции :)

Предлагаю всем начать профилировать винду для нахождения всех тормозящих функций  ;D

Давай исходники, а мы уж отпрофилируем :D

С исходниками каждый может, а по WinDbg слабо?  ;D

Я использую в проектах валгринд. Вполне успешно. Удавалось с его помощью находить утечки и проблемные места

это линуксовая софтина. на форточках тоже нужно иногда юзать.

Периодически использую по работе IBM Rational PurifyPlus for Windows (http://www-03.ibm.com/software/products/en/win). Вполне юзабельная штука, умеет встраиваться в MSVC. Например, можно ставить breakpoint на ошибки вроде Uninitialized Memory Read и сразу в отладчике смотреть как же это так получилось. Там же и профайлер есть вполне удобный.

User license: USD $1,770.00

чумово....
Особенно если для себя софтину смейкать надо, для домашнего пользования.

Только я ее на трекерах не нашел - а цена в штуку баксов, что-то не устраивает.  :D

Кстати, нашел неплохую статью по ошибкам в коде касающихся утечек и неправильной работы с памятью. У меня, да и у всех начинающих, это огромная проблема, поэтому оставляю линк на статью (http://logic.pdmi.ras.ru/csclub/sites/default/files/slides/20130429_dynamic_c_cpp_program_analysis-alexey_samsonov.pdf), буду очень рад комментариям всех продвинутых. Может быть, кто-то найдет ошибку или ложное высказывание.

Спасибо, OKTA. Dr. Memory понравился. Но надо внимательно почитать. Кстати, в этой статье рассматривается работа и с этой программой.

Еще одна просьба: выскажите мнение по поводу использования shared_ptr *(Shared Pointer STD).  Спасибо.

Ну я уже не раз высказывал. :)
Использовать везде и всегда. После того, как разберетесь с умными указателями и начнете их использовать проблемы утечек памяти (и других ресурсов) перестанут вас волновать как класс. :)

Нашел тему про shared_ptr. http://stackoverflow.com/questions/3628081/shared-ptr-horrible-speed
Правда ли?

Конечно медленнее. Там же внутри обертка с счётчиком.
Делали проект по приёму данных с оптоволокна - пришлось выкинуть нафиг все эти крутости аля "boost::shared_ptr". Ибо даже 10Гбит принять не могли - тормозило.

Мне даже страшно представить что вы с ними делали.
Покажите пожалуйста как вы их использовали при приеме данных?

Не я, а коллега, яро доказывающий что обычный указатели - сакс, а shared - крутотень!

Задача простая была - приём структур, анализ, отбраковка, передача "чистых" данных дальше.

Вот это и не понятно. Как он использовал shared_ptr в этой задаче, что была просадка в скорости?
Где здесь происходит интенсивная работа с указателями?

Везде где использовались указатели - данные. Структуры создаваемые из данных и иже с ним.

Это не убедительно. У меня (да и не только у меня) они используются в проектах с очень высокой нагрузкой и спокойно выдерживаю. Не представляю как указатели могут стать "бутылочным горлышком" при приеме и обработке данных.
Получается, что у вас создание/использование указателя соизмеримо с самой обработкой?

Можно подумать, что счетчик синхронизируется с сайтом майкрософт.

Очень понравилось. В основном чтение статей сводится к запоминанию инфы (часто без всякого осмысления). Здесь пытаются пробудить "соображалку"

За это допущение я получал  :) В общем случае нет, адрес может быть не кратен 8. И вообще присваивание long long компилятор может выполнить как 2 int'ов. Поэтому строго tbb::atomic

Ну тут очевидно - родительский конструктор еще не вызван, а executor уже щемится

Однако о др вещах я без понятия - напр что то за "shadow"  ???

Такие случаи возможны (напр при работе с геометрией) - хотя не так уж часты

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

В данном же случае, мы говорим про работу с сетью (прием/обработка/отправка), представляете задержки? Могут они быть соизмеримы?

Так вот же и привели (знакомая задача)

Та ну..  :) Зачем такие крайности? На всякое правило найдется исключение, это нормально

Я не могу предоставить вам тест, ведь у меня теперь нет ПЛИС'а, щемящего поток инфы по оптоволокну :)

Знакомая, только не понятно для чего автор использовать умный указатель со счетчиком? Это избыточно, есть другие умные указатели.

И как раз про такие задачи я и писал:
Для быстрого выделения одинаковых объектов лучше использовать пулы + unique_ptr, и это решение обгонит обычные указатели.
Самый большой прирост дает именно алгоритмическая оптимизация, а не отказ от конструкторов/деструкторов и умных указателей.

Вы про какие крайности?

Все верно, только "отказ" надо заменить на "использование"  :) Алгоритм там примерно такой
 
Нужно построить треугольники по множеству точек на плоскости. Строим вмещающий треугольник, затем добавляем в него точку за точкой. Добавленная попадает в какой-то треугольник, он разбивается на 3 новых. Затем ребра балансируются по Борису Николаевичу. Балансировка может вызвать изменение смежных тр-ков, в общем получается "волна" которая впрочем быстро затухает. Где-то видел анимацию видео, но навскидку не найду.

В общем типичная задача где у "грамотного" возникают проблемы :) Знает-то он может и много, но вот возиться со всем этим не хочет.  Бросается "изыскивать" готовое - что далеко не всегда приемлемо. А оптимизировать самому - так это ж велосипед! Умные указатели, bidirectional iterators и.т.п. - все это здесь "до одного места", знаток "не в своей тарелке" :). Поэтому человек с куда более скромными познаниями - но делающий задачу охотно, с желанием добивается лучших результатов.

Да, по поводу "балансировки", базовая задача:

Есть выпуклый 4-угольник  на плоскости. Каким образом лучше разбить его на 2 треугольника?  Др словами сформулировать критерий/правила "лучше"

Все. По делу сказать нечего. :)
Сразу вспомнились ужасы умных указателей и страшных итераторов... Уууу. :)

Да у "грамотных" всегда и все вызывает проблему. Вы уж смеритесь. :)

Ну хорошо хоть реагируете спокойно :) Не ужасы, просто в задаче роль этих вещей может быть ничтожно мала по сравнению напр с деталями алгоритма, организацией данных и др. Поэтому не следует переоценивать "умность" указателей (как и пользующихся ими :))

А кроме вас их никто не переоценивает. :)
Ими просто пользуются. :)
Это удобно. :)

А если сравнивать shared_ptr и QSharedPointer - отличия есть?

Когда-то проводил такие тесты, может пригодится :). Проект во вложении.