Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[54.224.52.210] |
|
Страницы: (3) 1 [2] 3 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
можно графически? Public Type struFileInfo Idx As Long Info As String * 124 End Type Public aFileInfo() As struFileInfo ... ReDim Preserve aFileInfo(i) |
Сообщ.
#17
,
|
|
|
Цитата BlackSun @ можно графически? https://ru.wikipedia.org/wiki/%D0%9A%D1%80%...%B5%D0%B2%D0%BE Цитата BlackSun @ Public Type struFileInfo Idx As Long Info As String * 124 End Type Public aFileInfo() As struFileInfo ... ReDim Preserve aFileInfo(i) Здесь overflow может случится из-за переполнения переменной i. При нехватке памяти ты получишь Out of memory. |
Сообщ.
#18
,
|
|
|
Так я ни слова не говорил ни о линейности, ни о массивах Коллекция - это всего лишь интерфейс, а реализацией уже пусть сам решает что ему надо, поведение массива, поведение связанных списков, множества, карты-словари, да что угодно. И да, хранение данных в коллекциях, как раз, реализуется таким образом, чтобы не получать такие ситуации как вышло у ТС, я же намекнул на многостраничное хранение данных и множества более мелких массивов) Автор же настаивает на массиве-монстре, всё в одном, да ещё и в линейном виде... |
Сообщ.
#19
,
|
|
|
Цитата VisualProg @ Так я ни слова не говорил ни о линейности, ни о массивах Имелась в виду встроенная в VB6 реализация коллекции которую я привел по ссылке - Collection. Цитата VisualProg @ И да, хранение данных в коллекциях, как раз, реализуется таким образом, чтобы не получать такие ситуации как вышло у ТС Мы еще не выяснили что там произошло у ТС, поскольку его ошибка вызвана не нехваткой памяти. За нелинейность придется также заплатить фрагментацией, скоростью и дополнительной памятью. Большой линейный массив данных нужно организовывать через файл-маппинг. |
Сообщ.
#20
,
|
|
|
Цитата TheTrik @ Здесь overflow может случится из-за переполнения переменной i i As Long Ошибка при i=663893. err.Description="Out of memory" Цитата VisualProg @ что имеется ввиду? многостраничное хранение данных |
Сообщ.
#21
,
|
|
|
Цитата BlackSun @ i As Long Redim не генерирует Overflow исключение. |
Сообщ.
#22
,
|
|
|
Сейчас выдало Out of memory, но ранее было Overflow, удивительно... Хотя, может я что-то напутал.
|
Сообщ.
#23
,
|
|
|
Цитата BlackSun @ Сейчас выдало Out of memory, но ранее было Overflow, удивительно... Хотя, может я что-то напутал. Значит не хватает нужного куска памяти. Меняй организацию данных. Во-первых, все ли 124 символа всегда используются? МБ сделать ее динамической? Во-вторых, String - UNICODE строка, нужен ли юникод? МБ обойтись многобайтовой реализацией? В-третьих, если доступ к данным в основном последовательный (не рандомный), то сделай фиксированный буфер и перехватывай ошибку обращения вне диапазона - подгружай нужную часть и корректируй индекс - идеально через файл-маппинг, система сама будет обновлять данные. |
Сообщ.
#24
,
|
|
|
Строка используется полностью, но что-то ужимать (пусть и в 2 раза за счёт байтового массива) - для меня не выход. Можно одновременно держать в памяти часть массива, это куча доп. кода для каждой простой операции, как, например, поиск в массиве. Если бы VB позволял создавать "постраничные" массивы, где первый индекс массива указывает на страницу(массив-страницу в памяти), то лучше бы я переписал код для работы с таким массивом.
|
Сообщ.
#25
,
|
|
|
Цитата BlackSun @ Можно одновременно держать в памяти часть массива, это куча доп. кода для каждой простой операции, как, например, поиск в массиве. Нет. На доступе это никак не скажется, разница только при подгрузке которая ловится перехватом исключения. Цитата BlackSun @ Если бы VB позволял создавать "постраничные" массивы, где первый индекс массива указывает на страницу(массив-страницу в памяти), то лучше бы я переписал код для работы с таким массивом. Ничто не мешает создать такой. |
Сообщ.
#26
,
|
|
|
Цитата TheTrik @ Как? Ничто не мешает создать такой. |
Сообщ.
#27
,
|
|
|
Цитата BlackSun @ Как? Public Type struFileInfo Idx As Long Info As String * 124 End Type Private Type tPage tData() As struFileInfo End Type Public aFileInfo() As tPage |
Сообщ.
#28
,
|
|
|
Цитата BlackSun @ что имеется ввиду? Цитата VisualProg @ Сделать "страничное хранение". Например, есть некая коллекция из 800 000 000 элементов, но, по факту, эта коллекция не один массив, а n массивов фиксированной длинны. Организацию доступа к конкретному элементу такой коллекции придётся придумать... За длину такого фиксированного массива можно брать, например 100 элементов. Далее, для того чтобы записать 400 000 000 элементов, тебе необходимо сгенерировать 4 000 000 массивов по 100 элементов, всё просто. Непрерывное свободное место объёмом в 100 элементов с куда бОльшей долей вероятности встретиться в ОЗУ, и, естественно, такие массивы уложить в памяти проще. Это я тебе пример привёл для поведения как у массива. Если же ты будешь использовать связный список - то там вообще не надо заморачиваться, он хранится по 1 элементу в памяти. Единственный минус связных списков - невозможно получить доступ к конкретному элементу сразу, для этого надо пройтись от начала или от конца списка по всей цепочки, и найти нужный элемент. Зато, добавление новых элементов, и удаление старых - моментальное. Короче, всё это - основы, я тебе уже книжки пересказываю, мог бы и сам почитать... |
Сообщ.
#29
,
|
|
|
TheTrik мне нужно постраничное хранение в памяти, а не постраничное чтение из файла, хотя, экономия памяти - тоже выгода. VisualProg, да про списки-то я знаю, а вот уверены, что коллекция лежит в памяти кусками? Сейчас потестим.
|
Сообщ.
#30
,
|
|
|
Цитата BlackSun @ TheTrik мне нужно постраничное хранение в памяти, а не постраничное чтение из файла, хотя, экономия памяти - тоже выгода. Файл маппинг - для больших линейных массивов данных. Если у тебя не очень большой массив, то можешь делать как тут Максимальный размер массива UDT. |