2013-07-05 2 views
1

Если я создаю или обновляю несколько списков очень, очень мало раз, в большинстве случаев только один раз, но я проверяю существование объекта в этом списке кучу раз, стоит ли конвертировать списки в словари и а затем проверить наличие ключа?Преобразование списков в словари для проверки существования?

Или, другими словами, стоит ли мне конвертировать списки в словари для достижения более быстрых проверок существования объекта?

+1

Что не так с синтаксисом 'if element in list'? Зачем вам нужно преобразовать 'list' в' dict' для этого? – Alex

+1

@Alex: Потому что это медленно! – jason

+0

Этот код у вас есть? Если это так, и важно найти стоимость O (1), то вы не можете сохранить в словаре/набор для начала? – Michael

ответ

4

Поиск в словаре быстрее, чем поиск в списке. Также будет вариант set. При этом:

Если «куча раз» означает «это будет 50% увеличение производительности», то идите на это. Если это не так, но делает код лучше для чтения, а затем ищите его. Если вам будет интересно это делать, и это не повредит, тогда идите. В противном случае это, скорее всего, не стоит.

1

Вы должны использовать set, так как из вашего описания я предполагаю, что у вас не будет значения для связи. См. Python: List vs Dict for look up table для получения дополнительной информации.

+1

Существует довольно хорошая информация о производительности [здесь] (http://interactivepython.org/courselib/static/pythonds/AlgorithmAnalysis/analysis.html#performance-of-python-data-structures). – Michael

0

случайный доступ (поиск) в словаре быстрее, но создание хеш-таблицы потребляет больше памяти. more performance = больше использование памяти

это зависит от количества элементов в вашем списке.

1

Обычно не важно настраивать каждую строку кода для максимальной производительности.

Как правило, если вам нужно найти более нескольких раз, создание set обычно стоит.

Однако учтите, что pypy может выполнять линейный поиск в 100 раз быстрее, чем CPython, тогда «несколько» раз могут быть «десятками». Другими словами, иногда имеет место постоянная часть сложности.

Вероятно, безопаснее всего использовать set. Вы с меньшей вероятностью обнаружите, что узкое место как система масштабируется, чем наоборот.

Если вам действительно нужно все микротонировать, имейте в виду, что реализация, кеш-кеш и т. Д. Могут повлиять на него, поэтому вам может понадобиться перекидывать по-разному для разных платформ, а если вам нужна производительность, что плохо, Python вероятно, был плохим выбором - хотя, возможно, вы можете вытащить горячие точки на C. :)

Смежные вопросы