Проблема с памятью

← →
VadimSpb (2005-12-04 11:22) [0]

Добрый день!
Возникла проблема, связанная с памятью.
Суть проблемы: Если подключаемся через ADOTable к таблице, где 60000 записей, размер программы в памяти увеличивается на ~6 МБ, если через запрос на объединение с другими таблицами (ADOQuery) - ~60 МБ.
Собственно на запросы пришлось перейти, т.к. если поля в ADOTable лукапить с другой таблицей, они потом не сортируются. Но в результате попал на память!
Таких запросов несколько + увеличится число записей. В общем такие расходы памяти неприемлемы.
Как решить эту проблему?

← →
sniknik © (2005-12-04 11:38) [1]

> Как решить эту проблему?
сменить логику с локально файловой на клиент серверную... и не только в программе, а в основном у себя в мозгах.

так например какой смысл тащить на клиента все 60000 записей? (в случае с jet com обьект обрабатывающий запросы можно рассматривать как sql сервер, впрочем он позволяет работать и локально)

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

+ избавься от. ADOTable/ADOQuer (вообще сними с палитры компонент и забудь про них) пользуйся ADODataSet/ADOCommand
(это в качестве дружеского совета. не по теме)

← →
Fay © (2005-12-04 15:40) [2]

2 sniknik © (04.12.05 11:38) [1]
> избавься от. ADOTable/ADOQuer
Почему? Давно хотел узнать...

← →
VadimSpb (2005-12-04 16:17) [3]

Поставил курсор на сервер и все значительно улучшилось.
Если будет достаточно пользователей-клиентов, то не "ляжет" ли сервер, если все будет в его памяти?
Чем будет лучше DataSet? Применил его вместо ADOQuery и все осталось по прежнему.

← →
sniknik © (2005-12-04 16:19) [4]

Fay © (04.12.05 15:40) [2]
а просто так. чтоб было. (надоело повторять одно и тоже) лучше ты обьясни, зачем они тебе нужны? что в них такого особенного, чтобы за них так упорно держатся?

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

← →
VadimSpb (2005-12-04 16:44) [5]

Форд продается уже полностью укомплектованным :-))
Нужны реальные доводы. Я читал у Архангельского, что в ряде случаев ADOQuery предпочтительнее. Разумеется надо отталкиваться от степени разумной необходимости. Какие явные преимущества DataSet?
Все-таки, как с курсорами на сервере?

← →
Fay © (2005-12-04 17:38) [6]

>> надоело повторять одно и тоже
Что именно повторять?
Не понимаю о чём идет речь. Я на этом форуме не первый год, и пока ни разу не видел аргументов к заявлениям вида "избавься от. ADOTable/ADOQuer (вообще сними с палитры компонент и забудь про них)".

← →
sniknik © (2005-12-04 17:48) [7]

> что в ряде случаев ADOQuery предпочтительнее.
по сравнению с чем? с ADOTable? двумя руками за.
по сравнению с ADODataSet? так ADOQuery это и есть ADODataSet, слегка подрихтованный молоточком по кузову. и не в сторону улутшений, а в сторону придать кузову "жигульную" форму.

> Какие явные преимущества DataSet?
DataSet основа всего, в том числе и Table(BDE)/ADODataSet, убери его и все рухнет. достаточно преимуществ?

> Все-таки, как с курсорами на сервере?
в смысле "как"? обычно, но используя их теряеш часть специфическую для локальных. а сортировка на локали судя по всему тебе нужна... в принципе можно попробовать обойтись индексами, но тут надо конкретнее в задачу "вникнуть".

да еще...
+ сожги Архангельского.... ;)

Fay © (04.12.05 17:38) [6]
> Я на этом форуме не первый год, и пока ни разу не видел аргументов
писал. не раз. видимо "разминулись".

← →
sniknik © (2005-12-04 17:58) [8]

> Fay © (04.12.05 17:38) [6]
основная "претензия" к ADOTable, т.к. при переходе с BDE думают стереотипами, раз есть компонент значит и работать также... и нарываются на грабли. после возмущаются "тормознутостью" всего ADO.
а это совсем другой компанент, усеченный и ограниченный ADODataSet. хотя, если знать что к чему через него можно и запросы выполнять... но это "слегка" через задницу.
ADOQuery уже чисто за компанию, и за то рушит логику ADO, где все делится на запросы возвращающие данные и нет. для возвращающих ADODataSet для не возвращающих ADOCommand. а почему для оних запросов нужен ADODataSet для других не отличающихся по смыслу ADOQuery а для третих ADOStoredProc (кстати забыл, тоже нафиг в корзину) понять уже труднее. для чего делить если с точки зрения ADO это одно и тоже?

← →
VadimSpb (2005-12-04 19:57) [9]

Хорошо, курсоры на сервере. Разве при этом на локальной машине их нельзя сортировать? Попробовал - сортируются!

← →
VadimSpb (2005-12-04 20:08) [10]

Как принято реализовывать ситуацию, когда необходимо просматривать все записи в таблице, а тащить всю слишком много? Насколько я понимаю, достаточно перенести то, что необходимо для экранного отображения с некоторым запасом. Затем по скроллу подгружать данные. Или я ошибаюсь?
Фильтрация не пройдет, нужна последовательность данных.

← →
Fay © (2005-12-04 22:27) [11]

2 sniknik © (04.12.05 17:58) [8]
Я правильно понял, что речь идёт не о каких-то "технических" проблемах?

← →
sniknik © (2005-12-05 00:02) [12]

VadimSpb (04.12.05 19:57) [9]
> Хорошо, курсоры на сервере. Разве при этом на локальной машине их нельзя сортировать? Попробовал - сортируются!
это у тебя не правильный мед. не с того улья. ты видать пробовал получить уже отсортированный рекордсет с сервера а не сортировать на клиенте...
(я понял нужна именно на клиенте. наверное ошибся)

VadimSpb (04.12.05 20:08) [10]
> Как принято реализовывать ситуацию, когда необходимо просматривать все записи в таблице ....
таких ситуаций принято избегать. всеми мыслимыми и немыслимыми способами.

> что необходимо для экранного отображения с некоторым запасом. Затем по скроллу подгружать данные.
это как раз при серверном курсоре и делается, докачивается по мере обращения. (резкий сдвиг скрола далеко вниз, и тормоза... ;)

> Фильтрация не пройдет,
какая фильтрация на 60тысячной таблице? избавляйся, это наследие тяжолого "локальнофайлового" прошлого получать нужное фильтром из общего набора данных (с таблицей это наоборот хороший вариант). на клиент серверном настоящем надо подумать, что именно тебе нужно и именно его и запросить... (в идеале)

> нужна последовательность данных.
какая? последовательность не гарантируется sql сервером, если только не задана явно сортировкой в запросе

Fay © (04.12.05 22:27) [11]
> Я правильно понял, что речь идёт не о каких-то "технических" проблемах?
технически ADOTable/ADOQuery/ADOStoredProc это одно и тоже и = ADODataSet, так какие могут быть технические проблемы?
считать технической упорное стремление затянуть весь несколькомилионный рекордсет на клиента и отфильтровать 10 нужных записей?

хотя и это было (технические), был глюк в реализации ADOStoredProc в самом начале ADO (узнал много позже про него т.к. не использую и не коснулось), был глюк в ADOQuery с получением параметра при раздельном внесении запроса как обычно с ним и делают. (аналогично не коснулось)
было кстати забавно читать про чужие грабли и думать "ай какой маладетц, прочитал, что это компоненты для "совместимости с мозгами привыкших к BDE", а оригинальное вот это , и решил не использовать... скольких проблем оказывается избежал и не заметил".
на королевстве дельфи по моему читал, там список "глюкавостей ADO" гдето был.
ну и если скорость нужна (на милисикунды счет идет) то тоже небольшое техническое преимущество у ADOCommand перед ADOQuery есть... когда множественное выполнение в циклах это заметно.
и т.д. по мелочи, всего не упомниш.

но это ерунда можно привыкнуть, смысла нет но можно, а в основном проблема конечно "мозгах", в силе привычке. и тут уже непонятно, ну сделали чтото новое, пользуйся им какое оно есть, зачем старые стереотипы на него "натягивать"? лучше оно облицованное старым фасадом не будет. хуже запросто.

← →
sniknik © (2005-12-05 00:24) [13]

вот статья которую читал
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=733

заметь кстати насколько сильны стереотипы, "типовые решения" исправляют тот же "кверик" про ADODataSet даже и не вспомнили, а ведь это на передаче ему "ломаного" запроса возникала ошибка, он то сделан под одну строку (CommandText). замени и горя не знай. с ним по другому как весь запрос целиком и не получится.
ну вернее это надо очень "постараться" написать
ADODataSet.CommandText:= "SELECT ";
ADODataSet.CommandText:= ADODataSet.CommandText + "* ";
ADODataSet.CommandText:= ADODataSet.CommandText + "FROM ";
.....

по диотски выглядит да? а ведь с ADOQuery так и было, только "замазано" дополнительной надстройкой - свойством "SQL".... (счас то уже исправили. наверняка буферизуют передачу. неохота смотреть), и никого не удивляло.

← →
Fay © (2005-12-05 04:53) [14]

2 sniknik © (05.12.05 00:24) [13]
Описаных проблем не встречал. Смоделировать (MSSQL) не удалось.

> ну и если скорость нужна (на милисикунды счет идет)
В это случае нужно работать без компонентов (ну разве что получить у ADOConnection его _Connection).

> для "совместимости с мозгами привыкших к BDE"
Указанные мозги никакого отношения к ADOQuery не имеют и хуже его не делают.

> ну сделали чтото новое, пользуйся им какое оно есть, зачем старые
> стереотипы на него "натягивать"?
О каком "новом" идёт речь? ADODataSet чем-то "новее" ADOQuery? Не замечал.

Пока я услышал только то, что ADOQuery чем-то хуже, но хуже он как-то по-странному - не понятно, чем же лучше ADODataSet?..

← →
sniknik © (2005-12-05 23:38) [15]

Fay © (05.12.05 04:53) [14]
> Описаных проблем не встречал. Смоделировать (MSSQL) не удалось.
значит повезло. и как ты это смоделируеш это сейчас? давно пофиксено все, смотри дату статьи.

> О каком "новом" идёт речь? ADODataSet чем-то "новее" ADOQuery? Не замечал.
это одно и тоже, говорил же.

> Пока я услышал только то, что ADOQuery чем-то хуже, но хуже он как-то по-странному - не понятно, чем же лучше
> ADODataSet?..
не собираюсь доказывать чем "А" лучше тойже "А" но в обертке от "Б".

вообще это твое дело, пользуешся пользуйся.

← →
sniknik © (2005-12-05 23:52) [16]

насчет скорости
http://delphimaster.net/view/3-1131457561/

> В это случае нужно работать без компонентов (ну разве что получить у ADOConnection его _Connection).
это не будет работать быстрее положенного рядом и подключенного к конекту ADOConnection-а, (имеется ввиду _Connection.Execute вызывать?) иначе зачем конект, без запроса.
т.к. постоянная работа со строкой (передача запроса), + нет параметров, + нет препаре команды.
в "нормальном" ADOCommand парметры и препаре есть, передачь строк нет.

← →
sniknik © (2005-12-05 23:53) [17]

к конекту ADOConnection-а => к конекту ADOCommand-а

← →
Fay © (2005-12-06 00:32) [18]

2 sniknik © (05.12.05 23:52) [16]
> имеется ввиду _Connection.Execute вызывать?
Да хоть бы и так.

> это не будет работать быстрее положенного рядом и подключенного к конекту
Зависит от "это". В определённых ситуациях (обычно - forward-only read-only recordsets) прирост скорости (в разы) можно получить. Я не пересказываю слухи, просто под рукой нет компактной "демонстрашки", а писать специально - лениво.

← →
sniknik © (2005-12-06 01:03) [19]

> В определённых ситуациях (обычно - forward-only read-only recordsets) прирост скорости (в разы) можно получить.
ну прямо откровение свыше. ;о))

не зависит от компонент, UniDirectional датасеты всегда получаются быстрее обычных, в силу некоторых причин (не надо заботится обратной связи. не поддерживаются букмарки. /может еще чегото)

> Я не пересказываю слухи, просто под рукой нет компактной "демонстрашки", а писать специально - лениво.
вообщето это ты спросил, т.е. тебе было надо. или спросил с умыслом наоборот меня переубедить? не получится.

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

> ну прямо откровение свыше. ;о))
> не зависит от компонент, UniDirectional датасеты
А что, ADODataSet бывает UniDirectional ?! Можно подробнее?

> у человека ускорение не в разы, в 200 раз
А с параметрами при ADOQuery не судьба?

> А что, ADODataSet бывает UniDirectional ?! Можно подробнее?
ВОТ! вот это я и назаваю непосредственным вредом от ADOQuery. в каждом посте твержу что это тот же, но замаскированный ADODataSet, но он мне приводит однонаправленые курсоры как аргумент за ADOQuery и тут же спрашивает а разве ADODataSet это позволяет.
еще раз. все что позволяет ADOQuery позволяет и ADODataSet т.к. единственное, что делает ADOQuery это передает запрос на выполнение ADODataSet (если так можно сказать о наследнике).
ни одного полезного свойства в ADOQuery не добавлено. все только убрано.

ADOQuery = ADODataSet с настройкой на тип команды cmdText, добавлена "нашлепка" в виде метода SQL, дла странных манипуляций с самим запросом при раздельном его внесении. (описано см. выше) . и метод ExecSQL {for TQuery compatibility} который тоже ничего не делает, только передает команду дальше в ADOCommand. все.

ADOTable = ADODataSet с настройкой на тип команды cmdTable. позволяет менять тип на cmdTableDirect специальным методом а не непосредственно у типа. добавлено перенаправление (переименован) DataSource в MasterSource для тойже совместимости с TTable.
и без пояснений, что это всетаки не таблица как в BDE, это всетаки запрос хотя таблицей и назван.
все.

ADOStoredProc = ADODataSet с настройкой на тип команды cmdStoredProc. ничего кроме "оригинального" вызова ExecProc (какой был у TStoredProc) не добавлено. все.

т.е. все что позволяет любой из них естественно позволяет и ADODataSet т.к. ни один непосредственно работой не занят, занят перенаправлением команд ADODataSet-у.

> А с параметрами при ADOQuery не судьба?
железный аргумент! но только "слегка" не по адресу. так еще можно говорить когда используется сложный и запутанный способ чтобы указать прямой, но не наоборот.
наоборот это я должен говорить зачем пользуешся ADOQuery, не судьба использовать "родной" компонент.

тем более "судьба" по оптимизации времени говорит, не надо делать лишних вызовов даже быстрых процедур, т.к. на вызов самих процедур тоже время расходуется. так что если можно обойтась то лучше обходится без посредников. пару вызовов сэкономим.

p.s. пора завязывать. переубеждение каждого сторонника ADOQuery слишком накладно по времени. а "скопом" они не переубеждаются (у меня почемуто чуство, что видел ты мои посты (> [6]), просто не воспринял написаное за аргумент. как и сейчас)

p.p.s. как не поймете, ADOQuery это не та "революция", что была при переходе с TTable на TQuery в BDE. в ADO это не более чем дань привычкам для тех кто с него(BDE) начал.
но, хотите пользоваться, ваше дело, пользуйтесь.
но без выяснений что лучше, одно и тоже это, разница только в мозгах, а так говорил уже, и через ADOTable можно запросы делать пользуясь методами предка (т.е. получается не хуже ADODataSet-а...).

2 sniknik © (06.12.05 9:19) [21]
Я не говорю, что ADOQuery предпочтительней.
Я просто не могу понять, почему его нельзя (категорически) использовать. М.б. я невнимательно читал, но пока я не понял.

2 sniknik © (06.12.05 9:19) [21]
> но он мне приводит однонаправленые курсоры как аргумент за ADOQuery
Нифига подобного - ADOQuery (и остальная братия) не знает про Unidirectional. Это было о пользе "бескомпонентной" работы 8).

> но пока я не понял.
не хотел. я про это с самого начала твержу. сами компоненты не причем но они накладывают стереотипы использования т.к. названы и призваны заменять аналоги из BDE. но аналогами как таковыми даже близко не являются.

зайди в базы и посмотри сколько народу пользуется ADOTable, и даже не задумывается (да и не хочет) , что это не тоже самое что TTable. дали "костылик" они на нем и ковыляют, не было бы его - пришлось учить новое в таком виде какое оно есть.

> Нифига подобного - ADOQuery (и остальная братия) не знает про Unidirectional.
наивный. зачем тогда свойство? из любви мелкософта вводить Fay в заблуждение? ;о))

просто оно зависит от свойств локальный/серверный курсор, + сам провайдер может не поддерживать однонаправленных. там где все условия совпадают оно должно работать (просто обязано).

кстати MSSQL поддерживает, ты вроде говорил с ним работаеш. смотри еще. доку прочитай в конце концов раз больше уже ништо не помогает... ;)

2 Anatoly Podgoretsky © (07.12.05 9:19) [26]
Точно. 8)
3 года назад мне это понадобилось, но я (каким-то образом) не нашёл. С тех пор не проверял, работал тупо с COM.

2 sniknik © (07.12.05 8:58) [24]

> > Нифига подобного - ADOQuery (и остальная братия) не
>знает про Unidirectional.
> наивный. зачем тогда свойство? из любви мелкософта
> вводить Fay в заблуждение? ;о))

Забудь. Это меня колбасит.

Вставлю свои 2 коп.
Поддержу Sniknik в плане "правильной психологии" работы с БД. Никто не утверждает, что нельзя пользоваться TADOQuery или TADOTable. Делать это точно так же глупо, как и запрещать носить галоши ВООБЩЕ.
Однако наличие подобного инструментария так или иначе стимулирует "ламерство" не слишком отягощенных пониманием ADO программистов, которые "по быстрячку" лепят проги, "работающие" с БД. Фиг его знает КАК, но работающие. В отладке такие программы могут не обнаружить свои дефекты, а вот по прошествии некоторого времени, когда база разростется, кол-во клиентов резко увеличится и т.д...

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

Проблема с памятью Найти похожие ветки