| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
потоки
Аврам © (2008-04-15 21:43:00)на форме валяется грид, заполненные данными.
строчек ~20-25 не больше.
по началу написал процедуру которая брала по очереди данные из каждой строчки и анализировала их. потом пришло в голову сделать все это дело через потоки, т.е. загружать например 10 потоков обрабатывать данные, потом по мере анализ освободившиеся потоки начинали обрабатывать следующие данные из грида, пока не проанализируются все.
можно ли так делать? если нет то почему? и как делать грамотней в этом случае?
решение о использовании потоков появилось когда попробовал запустить потоки по сразу всем данным типо того:
for i:=0 to grid.rowount -1 do
begin
gg := txz.create;
try
with gg do
begin
Inc(FThreadRefCount);
Resume;
end;
except on EConvertError do
begin
gg.Free;
ShowMessage('That is not a valid number!');
end;
end;
end;
end;
т.к. некоторые значения (данные) в гриде очень малы и высчитываются быстро, а быстрое появление результатов для меня важно.
Жду ответов и советов, спасибо!
ANB (2008-04-17 17:02:00) [41]
> Аврам (17.04.08 16:40) [101]
> афтар тут.
> да, больше времени занимает загрузка страницы с интернета,
> парсинг и анализ проходят быстро....млин все упирается
> в долгую скачку исходного текта страницы, прост опри разных
> параметрах запросы получаюстя разные, отсюда и разного размера
> страница для получения данных с сайта.
Есть смысл выкачать все, что может понадобиться, а уже на локале разбить на кусочки.
Мона, конечно, распараллелить выкачку с разными параметрами, но что то мне подсказывает, что загрузить одну большую страничку в одном потоке получится быстрее, чем даже в распараллелке выкачать кучу маленьких. Хотя, возможно, я и не прав. Шустрые качалки этот процесс распараллеливают.
Anatoly Podgoretsky (2008-04-17 16:55:00) [42]> Аврам (17.04.2008 16:40:41) [101]
Вот и Интернет появился, но это хоть какое то разумное объяснения применения потоков.
sniknik (2008-04-17 16:48:00) [43]> больше времени занимает загрузка страницы с интернета
вот против выноса загрузки с с интернета в отдельный поток думаю никто возражать не будет.
но ты то делаешь совсем другое, чтото что может вообще времени не занимает "распараллеливать" (да так что оно таки время занимать начинает).
почему и нужно четкое описание, что же всетаки делается.
Palladin (2008-04-17 16:42:00) [44]
> да, больше времени занимает загрузка страницы с интернета,
лично я в этом и не сомневался....
Аврам (2008-04-17 16:41:00) [45]к сожалению понял это только сейчас...
Аврам (2008-04-17 16:40:00) [46]афтар тут.
да, больше времени занимает загрузка страницы с интернета, парсинг и анализ проходят быстро....млин все упирается в долгую скачку исходного текта страницы, прост опри разных параметрах запросы получаюстя разные, отсюда и разного размера страница для получения данных с сайта.
ANB (2008-04-17 13:55:00) [47]
> Palladin © (17.04.08 13:26) [99]
>
> > Распараллеливание на клиенте с хранением всех данных в
> стриглисте
> > ?
> > С залезанием в него на каждый чих ?
>
> читать два последних абзаца [83] и мое ессе путь TListView'а
> до просветления... StringGrid уже давно не рассматривается.
> ..
Обработка 10-20 тысяч записей более 5 минут - это значит проблемы в генофонде. А если укладываться в эти рамки - зачем вообще нужна пользователю визуализация процесса ?
Palladin (2008-04-17 13:26:00) [48]
> Распараллеливание на клиенте с хранением всех данных в стриглисте
> ?
> С залезанием в него на каждый чих ?
читать два последних абзаца [83] и мое ессе путь TListView'адо просветления... StringGrid уже давно не рассматривается...
ANB (2008-04-17 13:20:00) [49]
> которая и делает распаралелливание оптимальным решением.
> ..
Распараллеливание на клиенте с хранением всех данных в стриглисте ?
С залезанием в него на каждый чих ?
Для сведения - оракл прекрасно умеет получать данные по HTTP протоколу.
А подводных камней при распараллеливании в нем намного меньше.
Palladin (2008-04-17 13:17:00) [50]
> Т.е. 100 раз первую сто раз вторую.
> >типа for i:=0 to count -1 do begin
я вижу это так: у него просто два списка один как в [34], первого уровня, второй другой как [8] по P (id)
> думаешь 100 раз проверка идет одной и той же строки? так
> сказать для гарантии результата?
нет, у него просто для одного P (id) - 100 значений Z по которым он считает, расчет многих Z может разультатов не дать (см [30])... а ему нужен первый получившийся результат... потому многопоточность будет оптимальней последовательности.
> без четкого описания "обработки" автором
ладно, согласен, ждем аффтора... весна покажет кто где гадил :)
Dennis I. Komarov (2008-04-17 13:17:00) [51]> [94] Palladin © (17.04.08 13:09)
ну возможно...
НО
> p.s. бред это все, без четкого описания "обработки" автором.
> посему надо закругляться.
sniknik (2008-04-17 13:11:00) [52]> Я предлагал. У меня подозрение, что БД выполнит алгоритм обработки намного шустрее и распараллелка просто не понадобится.
про нужность "распараллелки" согласен, единственное БД это всетаки дополнительные заботы. и если можно обойтись без нее, я бы постарался обойтись.
а каким образом оптимизировать обработку с помощью датасета или динамического массива под TreeView в принципе не суть важно. датасет просто потребует меньше усилий при больших возможностях.
> перечитал [34] никаких намеков на поиск значений среди других не увидел...
> обычная процедура как я делал с самого начала без потоков брала первую строчку из списка и пускала в процедуре анализ этой строки.
> Переменная count как раз говорит сколько раз надо проверить каждую строчку.
> Т.е. 100 раз первую сто раз вторую.
> типа for i:=0 to count -1 do begin
> Если найден результат по заданым мной критериям и i= 19 то в поле NY мы добавляем результат например 0,0102
> и переходим к анализу строчки с id =2 и т.д.
думаешь 100 раз проверка идет одной и той же строки? так сказать для гарантии результата?
p.s. бред это все, без четкого описания "обработки" автором. посему надо закругляться.
Palladin (2008-04-17 13:09:00) [53]
> Dennis I. Komarov © (17.04.08 13:05) [93]
и ты [30] не понял... там есть ключевая фраза, которая и делает распаралелливание оптимальным решением...
Dennis I. Komarov (2008-04-17 13:05:00) [54]> а в выборе оптимального метода решения задачи
А вот этого мы так и не узнаем, т.к. [38] и [51]
Palladin (2008-04-17 13:00:00) [55]
> sniknik © (17.04.08 12:52) [91]
перечитал [34] никаких намеков на поиск значений среди других не увидел...
> ANB (17.04.08 12:47) [90]
а ты читал [30]? вдумчиво читал?
sniknik (2008-04-17 12:52:00) [56]> а смысл?
имхо достаточный смысл, если там (что упоминалось) есть частый поиск значений одних данных в других.
ANB (2008-04-17 12:47:00) [57]
> а смысл?
Смысл - не в увлеченном программировании потоков, содержащем достаточно много подводных камней, а в выборе оптимального метода решения задачи.
> Никак производительность, нормально спроектированной, многопоточной
> системы не будет страдать от этого.
Выделенное является главным.
Я не писал о полном запрете на работу с VCL из потоков. И если меня поняли не так - уточнил это в следующем посте.
Никто не запрещает сложить все данные для расчета в визуальный компонент и лезть через синхронизе к нему из тысячи потоков. Только быстрее чем один они скорее всего работать не будут.
Palladin (2008-04-17 12:39:00) [58]
> ANB (17.04.08 12:29) [87]
Очень редкий случай, когда при распараллеливании не нужна синхронизация, а в случае синхронизации - всегдаможет возникнуть ситуация, когда один поток должен подождать пока не отработает какой то другой. Так что это в порядке вещей. И так категорически заявлять о запрете на обращение к VCL в потоках не нужно. Никак производительность, нормально спроектированной, многопоточной системы не будет страдать от этого.
> sniknik © (17.04.08 11:31) [86]
ну да... семейство inmemory dataset'ов никто не отменял...
но, как ты верно отметил по поводу "подходят для задачи", если собаке для выполнения, ее собачьих функций, понадобилась бы пятая нога я думаю она у нее была бы. а так, ну можно и пришить хирургически, или искусственную присобачить... :) а смысл?
ANB (2008-04-17 12:36:00) [59]
> БД то как раз никто и не предлагал.
Я предлагал. У меня подозрение, что БД выполнит алгоритм обработки намного шустрее и распараллелка просто не понадобится.
ANB (2008-04-17 12:29:00) [60]
> обоснуй. я вот обращаюсь...
Можно и обращаться. Но если это делать корректно, то потоки будут ждать друг друга.
| |
Страницы: 