| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Array [0..X] [D4, Win2k]
Kolya © (2002-10-02 02:28:00)Здравствуйте Мастера!
Моя программа работает с array of long. В 90% случаев требуются всего лишь 50-100 переменных, но иногда может потребоватся и несколько тысячь. Мне не хочется создавать array с 5000 переменных, поскольку это будет занимать очень много памяти (5000 x 4b = 20k). Гораздо лучше было бы сделать array с 50 переменными и только в 10% случаев разширять его до 5000. Возможно ли это? Заранее спасибо!
Alex4444444444 (2002-10-02 14:11:00) [21]To KSergey (iz Delphi help):
memory manager zaprashivaet u OS pamyat" kuskami po 1M i commit ee (uzh ne znayu, kak eto skazat" po russki) kuskami po 4K. (Na skol"ko ya znayu, nel"zya v principe poluchit" stranitsu ne kratnuyu 4K, no eto uzhe detali.)
Mike Kouzmine (2002-10-02 13:12:00) [22]Речь не о том, а то что считать байты пора заканчивать, именно, я не знаю, что вы пишите, может систему оповещения о ядерной атаке, которая должна отслеживать миллион объектов в реальном времени, я занимаюсь базами данных, где для манипулирования большими объемами данных используются другие механизмы. Я хотел сказать, что для больших объемов данных надо использовать базы данных, а если вы используете массивы, то флаг в руки.
Теперь отвечу -
"Не знаю как делает MBo, а я - элментарно: завожу переменную, в которой это все отслеживаю. (переменная жрет память? Так вроде байты мы перестали считать?)" - а если ошибка и не увеличился счетчик (любое исключение), да не одно? Универсальность и надежность подразумевает накладные расходы и надо это принимать или не принимать. Что вы и делаете (не принимаете).
KSergey (2002-10-02 12:18:00) [23]
> Mike Kouzmine
Как некоторое дополнение: тут речь не о байтах и мегабайтах: если для решения задачи необходимы террабайты памяти и заказчик готов за это платить (возможно, что другого пути просто нет), то сколько угодно! Но в данном вопросе вы элементарно ошибаетесь, и вам просто указывают на ваши ошибки, при этом, заметьте(!) не принужная следовать укозявкам.
Или вы посещаете форум для каких-то других целей? ;)
KSergey (2002-10-02 12:08:00) [24]
> Mike Kouzmine (02.10.02 10:17)
> Странное замечание Polevi © (02.10.02 10:09).
А чем оно странное?! Абсолютно правильно!
[Все что написано далее не совсем буквально так работает в вндовс, там защищенный режим, но в принципе довольно близко]
Тут ведь вот в чем дело: выделили, например, памяти 1 байт. Теперь говорим: "не, надо 2". Операционка говорит "Ок", буфер в 1 байт бросает, помечая его как свободный, выделяет в другм месте буфер в 2 байта (копируя туда данные). А мы ей тут опять: "А не, теперь 3 надо". Операционка опять бросает буфер в 2 байта и выделяет новый - длиною в 3 (копируя туда данные). Ну и т.д.
Во-первых, вы заметили, сколько копирований и прочих накладных расходов произошло?!
Во-вторых, буфера в 1 и 2 байта лежат пустыми, дефрагментируя память, при этом они вроде как пустые, но при следующей операции выделения памяти например в 500 байт ее может и не хватить, т.к. нет сплошного подходящего куска, а есть много мелких... Да. операцонка их еще иногда склеивать начинает - тоже процесс не из быстрых.
Почему операционка постоянно выделяет новый буфер а не удлинняет имеющийся? Так вообще-то не одна наша программа крутится, это раз. А два - и наша программа не один раз выделяет всякие кусочки в памяти - имеющемуся буферу, возможно, просто некуда расти - за ним уже лежит блок, выделенный в другом месте приложения (только не говорите, что вы выдляете память в одном месте и все. А как себя ведет и что делает VCL вы в курсе? (не в смысле, что ведет она себя плохо, а просто она тоже постояно выделяет/освобождает память)
Не спешите в меня плевать, я понмаю, что все оно не совсем так, что операционка выделяет не по 1 байту, а кусками, крантыми какой-то величине (Win по 4кБ, если не ошибаюсь) и в пределах этого куска размер буфера просто наращивается, но это актуально при выделении по 1 байту на раз. А что, если каждый раз увеличение больше, чем квант (один или несколько) выделения памяти? Тогда "предусмотрительность" (хотя и не в ней дело, но пусть будем думать, что это так) операционки нас ну никак не спасает. Память все равно дефрагментируется.
Так что алгоритм, предложенный MBo © (02.10.02 09:37) как раз очень правильный и разумный.
> Mike Kouzmine (02.10.02 10:05)
> MBo © (02.10.02 09:48) а как ты определишь сколько массив
> имеет реальных значений.
Не знаю как делает MBo, а я - элментарно: завожу переменную, в которой это все отслеживаю. (переменная жрет память? Так вроде байты мы перестали считать?)
(К стати, рекомендаци выделять память относительно крупными блоками есть во всех книижках, где разговор заходит о динамическом распределении памяти (вне зависимости от рассматриваемого языка программирования и компилятора), если уж все вышенаписанное вас не убеждает.)
Polevi (2002-10-02 11:06:00) [25]2Mike Kouzmine (02.10.02 10:52)
часто речь идет не о неделях а минутах, но вам лень мозги напрягать, у вас работодатель богатый
и что это за МОЙ подход такой интересно ??
то есть по вашему есть американский подход а есть какойто другой, которому я следую, так что ли ?
вы когда работу будете искать другую, в резюме свой подход опишите, будет куча предложений
Игорь Шевченко (2002-10-02 11:00:00) [26]Mike Kouzmine (02.10.02 10:52)
Жаль, вы не американец. Или пишете программу для использования в единственном экземпляре. Иначе посчитали бы, во всколько обойдутся расходы на железо у потенциальных пользователей вашей программы и сравнили бы со стоимостью усовершенствования алгоритма.
Mike Kouzmine (2002-10-02 10:52:00) [27]У американцев есть хорошая привычка считать деньги, зачем тратить больше денег на охрану гос секрета, если его опубликование принесет меньший урон, так и здесь - моему работадателю выгодней получить проект пораньше, доплатив 20 долларов за железо, чем я буду вылизывать алгоритм неделю. Хотя такой ситуации я не припомню. А ваш подход устарел еще при переходе на 386 процессоры. А размышления о байтах, мегабайтах и прочем железе - притянут за нос.
Polevi (2002-10-02 10:40:00) [28]2Mike Kouzmine (02.10.02 10:17)
сначало байты не считаем, потом мегабайты в файл подкачки, а может просто алгоритм надо передумать по другому ?
иногда несколько строчек кода может в десятки раз снизить треббования к памяти и процессору, но щас это типа не модно головой думать, пусть ОС за нас думает и юзеры за мегабайтами в магазин бегут
MBo (2002-10-02 10:23:00) [29]>Mike Kouzmine
В разных ситуациях и действовать нужно по-разному.
Если имеется крупный массив увесистых записей, просто нелепо при каждом добавлении одной записи делать реаллокацию.
Вот и TList подобным образом работает - по достижении предела добавляется место сразу под несколько указателей.
Mike Kouzmine (2002-10-02 10:17:00) [30]Странное замечание Polevi © (02.10.02 10:09). Мои программы и на 166 работают не проваливаясь (ну кроме длительных запросов к базе), и время прошло, когда надо было считать байты.
Кот Бегемот (2002-10-02 10:14:00) [31]Винда достаточно умная (???) все равно, выделяете вы память по биту или по метру, засунет ее в файл подкачки :(
Polevi (2002-10-02 10:09:00) [32]а потом все удивляються - мой суперпупер п4 тормозит !!
Mike Kouzmine (2002-10-02 10:05:00) [33]MBo © (02.10.02 09:48) а как ты определишь сколько массив имеет реальных значений. Что значит замедляет работу? На С1000 что так, что эдак - лишние доли секунды еще ни кому не мешали, зато я могу определить for i := 0 to High(Arr) do не парясь и не заботясь о определении - какая реальная длинна массива. И добавлять проще - SetLength(Arr,High(Arr) + 1);
MBo (2002-10-02 09:48:00) [34]проблем в общем нет, но лишние действия ни к чему. Это замедляет работу программы
raiv (2002-10-02 09:44:00) [35]Я этим постоянно пользуюсь и никаких проблем (D6). Раньше я это делал на C++. А в книгах по Delphi даже советуют это делать правда для D6. К тому же ты берешь ровно столько памяти - сколько нужно.
MBo (2002-10-02 09:37:00) [36]>raiv
Нехороший совет ;(
Постоянная реаллокация дин. массива ни к чему.
Эмпирическое правило: сразу задать такой размер, которого хватит в 80% случаев, при заполнении массива увеличивать длину на 20-25%
raiv (2002-10-02 09:20:00) [37]Советую определять размер динамического массива по мере чтения (поступления)данных.
....
SetLength(arL,I);
Чтение I числа
Inc(I);
...
VAleksey (2002-10-02 09:06:00) [38]не забудь освободить динамический массив после работы
arL:=nil
Polevi (2002-10-02 09:02:00) [39]>Кот Бегемот © (02.10.02 08:59)
молодец, чем больше памяти жрет программа, тем она круче !!
Кот Бегемот (2002-10-02 08:59:00) [40]Блиннн, Kolya ты извращенец
Купи памяти :-\
У мя массывы занимают по несколько метров -
Например 84000*64 - и я не парюсь
20к - даже для вируса мало
| |
Страницы: 