2013-06-04 2 views
1

Я столкнулся с этой статьей: Should you ever use Linked List. Он ссылается на то, что с учетом технологических достижений в доступных структурах памяти и ОЗУ, использование массивов будет лучше, чем Linked List.Связанный список по-прежнему актуальный?

Там же старый вопрос When to use a linked list over an array/array list?

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

+1

Я боюсь, что даже с технологическими достижениями вставка/удаление в массивах по-прежнему не может выполняться в постоянное время. Итак, нет. –

+0

Да, аргументы сохраняются. Но привязанные списки все еще используют их. – Joni

+1

Ядро linux использует связанные списки ** широко **, а также делает много другого программного обеспечения. Итак, да, уместно. –

ответ

4

Глупости. O (n) никогда не будет биться постоянно. Любое использование списков, необходимых для корректной работы с вставками с сохраненными итераторами, будет использовать связанные списки. Они являются фундаментальной структурой и не исчезнут.

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

У нас быстрые процессоры сейчас, поэтому часто не нужно беспокоиться о нескольких дополнительных инструкциях, которые могут потребоваться при реализации наших структур данных. Мы можем взглянуть на то, что мы используем, выработать то, что у нас есть, и выбрать наши структуры на основе их асимптотических характеристик. Это также делает код более удобным для обслуживания: вам не придется менять код, если вы обнаружите через шесть месяцев, что для n = 100 список будет быстрее. Профилирование - это тяжелая работа, поэтому мы должны быть очень удобны в дни загрузки процессора, чтобы выбрать структуру с алгоритмическими свойствами, которые мы хотим, а не гадать на векторе.

+0

Некоторые вещи с линейной сложностью времени избили некоторые вещи с постоянной временной сложностью для многих интересных значений n. Также обратите внимание, что массивы поддерживают некоторые операции в O (1), которые принимают связанное линейное время списка, а другие асимптотически одинаковы для обоих. Что касается ограниченного времени вставки: из того, что я слышу, вы все равно привязывали все размеры, а затем заранее выделяли для этого достаточно памяти. Быстрое динамическое распределение памяти в реальном времени очень сложно. И люди, которые беспокоятся о эффективности кеша, в любом случае не используют интерпретаторы (для чувствительного к производительности кода) ... – delnan

+0

... И «алгоритмически более приятный» (который, как я полагаю, относится к аккуратным кодам/псевдокодам) субъективен и сильно зависит от проблемы. Это не значит, что связанным спискам нет места, они, безусловно, это делают. Я просто недоволен тем, как вы пытаетесь продать эту правду. Как говорится, не стреляйте сообщение ;-) – delnan

+0

@delnan, хорошо это было немного аргументированный в тон. Теперь я стал более нейтральным. Я согласен с вашими очками. Благодаря «алгоритмически более приятному» я имел в виду объективно быстрее асимптотическую производительность (хотя да, выбор для написания кода, который масштабируется по умолчанию, является само по себе эстетическим). –

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