Увеличит ли размер резерва стека и размер фиксации стека производительность приложения?
У меня есть приложение, которое максимально использует рекурсивные функции. В основном это анализатор строк, который использует хеш-карту в качестве своей структуры данных. Мы сталкиваемся с проблемой, когда для сложных и длинных струн производительность сильно падает. Мы не осмеливались касаться хэш-функции, опасаясь регресса. Наблюдаются массивные рекурсивные вызовы функций, которые, как мы подозреваем, вызывают проблемы с производительностью. Приложение на основе C ++ (Windows), разработанное в VS 2008
Увеличит ли размер резерва стека и размер фиксации стека производительность приложения? ИЛИ ЖЕ
Удастся ли избежать проблем с нехваткой памяти, с которыми мы сталкиваемся, но не часто
Решение
Использование стека само по себе существенно не повлияет на производительность. Возможно, что стоимость выполнения вызовов функций (которые являются рекурсивными вызовами) составляет значительную часть времени выполнения вашей хэш-функции, и если это так, возможно, что итеративная версия будет быстрее.
максимальный использование рекурсии в C ++ потенциально неэффективно, а также несколько опасно, поскольку размер стека ограничен. Например,
size_t hash(const std::string &s) {
if (s.size() == 0) return 0;
return s[0] + 31 * hash(s.substr(1));
}
Это, вероятно, неэффективно для два причины (накладные расходы на вызов и вероятность того, что он распределяет нагрузки по строкам), а также приведет к сбою при стекопереработке при передаче достаточно длинной строки.
Мы не посмели коснуться хэш-функции, в страхе регресса
Даже помимо производительности, хеш-функция, используемая в хэш-карте, должна быть изолирована для простоты обслуживания — одна копия кода и нигде не предполагается, что используется какой-либо конкретный хеш-алгоритм.
Если вы можете изолировать хеш-функцию, то вы можете осмелиться прикоснуться к ней. Таким образом, вы можете легко сравнить различные алгоритмы хеширования и разные реализации (включая рекурсивные / нерекурсивные), чтобы увидеть, решают ли они вашу общую проблему производительности.
Если вы не можете изолировать хеш-функцию, вы извлекли урок о дизайне кода. Вы все еще можете заменить его и получить представление о том, влияет ли это на производительность без зная наверняка, что код все еще правильный. Если вы можете сделать это быстрее, то стоит попытаться исправить это (изменив остальную часть кода, чтобы изолировать хеш-функцию, а затем заменив ее). Если лучшая хеш-функция, которую вы можете придумать, не является быстрой, тогда не имеет значения, правильна она или нет, поскольку нет никаких оснований ее использовать.
Другие решения
Увеличит ли размер резерва стека и размер фиксации стека производительность приложения?
Почти наверняка это не будет иметь никакого значения для производительности.
Будет ли это избежать проблем с нехваткой памяти, с которыми мы сталкиваемся?
Нет. Если у вас заканчивается пространство стека, вы получаете ошибку переполнения стека, а не нехватку памяти.
detector