Comments 10
Отступы между заголовками списков и, собственно, их телом, кажутся здороватыми...(
Не находите?
Не-а, не пробовали. У меня, если честно, всегда было представление о фаззинге, как о средстве тестирования, в первую очередь, именно безопасности приложений.
По поводу того, что делали (немного продублирую статью) - профилирование и правки по его результатам. Важный момент - именно по результатам, так как одни и те же по сути правки могут давать улучшение, если их сделать в одном правильном месте, и вообще пройти без толку, если сделать в 10 неправильных.
Ну и + мониторинг отжора памяти / времени выполнения, чтобы держать руку на пульсе.
И регулярный статический анализ PVS-Studio с помощью PVS-Studio - это классика. :)
Хотя тут (если говорим про C#) речь в целом про ошибки, а не что-то специализированное для производительности.
Вы очень правильно заметили про приоритезацию / распределение ресурсов. :)
Тут стоит вспомнить и про другие направления. Например, правка false positives или усиление, скажем, security направления. Что важнее, работать правильно на "всяком мусоре" или выдавать меньше false positives на реальных кейсах? Быстрее работать на реальных проектах или, опять же, на "всяком мусоре"? :)
Кто знает, сколько ещё пользователей не такие терпеливые, как этот и просто забивают (или наоборот, страдают и думают, что это норма)
Увы, да, неизвестно. :( Но опять же, применимо и к другим направлениям, таким как те же false positives и т.п.
О, у меня скоро будет (надеюсь) интересная статья про "настоящие баги" и предупреждения статического анализатора. :)
Не надеюсь ни в чем убедить, но было бы забавно через годик прочитать "Как мы случайно начали фаззить PVS студию и к чему это привело" :)
Кто знает, кто знает. :) Эта статья тоже не планировалась в прошлом году)
Слава баг-репортам, или как мы сократили время анализа проекта пользователя с 80 до 4 часов