Список <> Лучше к init с максимальной способностью и только использует часть этого или init без способности

У меня есть a List<MyStruct> то, что я инициализирую, чтобы быть пустым, и я буду населять эту структуру в петле, поскольку я разбираю данные. Я знаю, что есть максимальное возможное количество записей, которые будут вставлены в этот список. На данный момент позволяет, говорят 1000. Однако после моего парсинга этих 1 000 записей я могу закончить тем только, что поместил 2 в Список. Так должен я инициализировать Список со способностью 1 000 или не определять способность и просто добавлять несколько записей. Это могло однако закончить тем, что добавило все 1000. Что лучший способ работа мудра?

8
задан jamone 22 January 2010 в 10:25
поделиться

5 ответов

Если он действительно может сильно варьироваться, то вы хотели бы не установить емкость. Для большинства коллекций емкость удваивается, поскольку она встречается (с емкостью по умолчанию 16, я верю), поэтому ваша мощность будет очень внимательно подойти к вашему максимуму, когда вы его заполните.

9
ответ дан 3 November 2019 в 13:09
поделиться

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

Во-вторых, иногда детали реализации важны, а вот случай, когда оно есть. Способ реализации в списке - это динамически вырабатываемый массив запуска с определенной емкости и удваивает размер каждый раз, когда требуется отрастание. Это означает, что если вы добавляете n , объект в вновь созданный список, будет o (log n) ROSTHTS, и вы будете не более тереть O (N ) Пространство. Если только память не будет напряженным в вашей системе (может быть, вы работаете .NET CF на мобильном телефоне) Это не так большая сделка. И из перспективы производительности, разбор ваших записей, вероятно, потребляет значительно больше времени, чем отрастание. Таким образом, это также вряд ли будет фактором.

3
ответ дан 3 November 2019 в 13:09
поделиться

Перед началом считывания значений из первой строки необходимо вызвать next () . beforeFirst ставит курсор перед первой строки, поэтому данные для чтения отсутствуют.

-121--917790-

Необходимо переместить указатель на первую строку, прежде чем запрашивать данные:

result.beforeFirst();
result.next();
String foundType = result.getString(1);
-121--917792-

Учитывая, что список мал для начала, лучше не инициализировать его. Это облегчит чтение кода без заметного влияния на производительность.

0
ответ дан 3 November 2019 в 13:09
поделиться

, вероятно, лучшее, что нужно сделать, - это компромисс. Инициализируйте список к чему-то вроде 256.

-1
ответ дан 3 November 2019 в 13:09
поделиться

не имеет значения. Не оптимизировать микрооптимизировать. Установите емкость, если у вас есть хорошая идея, это примерно на нужную сумму. Под капотом список удваивается каждый раз, когда он растет, поэтому количество роста составляет o (log (n)) . Это должно быть довольно эффективно.

21
ответ дан 3 November 2019 в 13:09
поделиться
Другие вопросы по тегам:

Похожие вопросы: