> -- Евгений Темиргалеев писал(а):
> Ваш вариант --- оптимизация, о которой думают потом.Если бы забота была о предельной ясности, а не об оптимизации, то эти линейные поиски были бы вынесены в отдельные процедуры.

viewtopic.php?p=69699#p69699> -- Илья Ермаков писал(а):
> я вообще всегда стараюсь их выкидывать в отдельные процедуры, чтобы нормально понималось. Представьте, насколько упадёт быстродействие в Вашем-моём варианте, если я его структурирую по процедурам, как "душа просит".Я вчера первым делом написал эти три линейных поиска в трёх процедурах. Замедлилось примерно на 40% по сравнению с вашим "ЦД" или, значит, примерно раза в три по сравнению с моим конечным вариантом. Это цена предельной ясности.> -- Peter Almazov писал(а):
> Можете еще ускорить, т.к. в самом внутреннем цикле есть лишняя индексация words[w], где w внутри цикла не меняется.Я так поначалу и сделал, но к своему удивлению оказался не прав. Оказывается индексация words[w][j] на современных процессорах и компиляторах работает даже быстрее чем сначала закэшировать byte[] tmp = words[w]; а потом использовать tmp[j]. Возможно в 32-разрядном Блэкбоксе такая оптимизация и окажется полезной, но в 64-разрядном C# она точно оказывается вредной.> -- alexus писал(а):
> При больших словарях (от 100 слов) целесообразно использовать другой алгоритм решения: 1. Отсортировать слова в словареЯ тоже так подумал когда вчера с работы домой ехал. Наверное можно даже отсортировать просто по первой букве. Составить таблицу, что слова начинающиеся на букву t лежат в диапазоне range[t].begin .. range[t].end.> -- alexus писал(а):
> Кстати, забыл отметить, что подход/алгоритм, предложенный в предыдущем моём сообщении, позволяет выполнять параллельный поиск (в отличие от цикла Дейкстры)+1