Оптимизация общего списка .net, касающаяся емкости - PullRequest
0 голосов
/ 06 мая 2011

В настоящее время я работаю с приложением, которое будет выполнять следующие действия.

// Initialize a list: 
myList = new List<aPoint>;
while(WeHaveMoreData)
   myList->Add(ReturnNext1000Points());

У меня нет возможности узнать общий размер списка с самого начала. Из того, что я прочитал, List<> - лучший способ справиться с таким количеством поступающих данных (может превышать 500 000 записей).

Мне интересно, должен ли я обрабатывать список (дать ему начальные значения или увеличить лимит, если он нужен)?

Как мне подойти к оптимизации такой процедуры?

Ответы [ 4 ]

3 голосов
/ 06 мая 2011

Если у вас есть приблизительное значение общего количества записей, вы можете установить емкость списка, иначе оставьте его расти.Это довольно оптимизировано, просто убедитесь, что у вас не хватает памяти.Другой подход заключается в использовании ленивого итератора, который не загружает весь список в память:

public IEnumerable<aPoint> GetPoints()
{
    while(WeHaveMoreData)
    {
        yield return new aPoint();
    }
}

Только после того, как вы начнете выполнять итерацию, записи начнут извлекаться одна за другой и сразу же освобождаются:

foreach (var point in GetPoints())
{
    /// TODO: do something with the point
}
2 голосов
/ 06 мая 2011

Первое правило: преждевременная оптимизация - корень всего зла. Если производительность не является проблемой, оставьте все как есть. В противном случае вы должны попытаться установить начальный размер списка около AverageExpectedSize/0.7.

1 голос
/ 07 мая 2011

В общем, я бы сказал, что если вы не знаете, сколько элементов в пределах скажем +/- 20%, то вам, вероятно, следует просто слепо добавить в список, а не угадывать емкость.

Список отличается от массива, когда дело доходит до добавления при заполнении. Помните, что список удвоит свою емкость, как только вы превысите емкость. Так, например, если ваш список имеет текущую емкость 128 элементов, и вы добавляете элемент, который составляет 129 элементов, список изменит свой размер до 256 элементов. Тогда для следующих 128 добавлений вы не изменяете размер списка вообще. Как только вы доберетесь до 257, он удвоится до 512, и процесс повторяется.

Таким образом, у вас будет O (log (n)) изменения размера в вашем списке.

1 голос
/ 06 мая 2011

Я также думаю, что вы не можете оптимизировать это много ... Я думаю, что вы могли бы сделать немного лучше в некоторых конкретных случаях, поэтому у меня есть вопрос - что вы будете делать с данными потом? Кроме того - вы хотите оптимизировать для памяти или скорости?

Типичная реализация списка будет увеличивать емкость в 2 раза каждый раз, поэтому, возможно, вы могли бы сэкономить некоторое пространство, имея List<aPoint[]>, в котором было бы гораздо меньше элементов, поэтому было бы меньше вероятности, что у вас будет несколько 100 тыс. Свободных мощностей. Но это будет иметь значение только в том случае, если у вас почти закончится память - скорее всего, в любом случае будет потрачено гораздо больше памяти на сами данные.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...