моя программа получает по сети данные размер которых порядка 4 Метров
и таких данных может одновременно приходить до 3 штук
их нужно держать в памяти причем длина данных изначально не известна и колеблиться от 3 метров до 8 метров, играться с выделением таких объемов мне кажеться не правильным, писать в файл нельзя по ТЗ, обрабатывать на лету в принципе невозможно...


Какие есть идеи, по поводу удержания данных до их обработки или всетаки придеться играться с динамическим выдилением

Step
А если просто выделить сразу 8*3 = 24 Метра, это ж не так уж и много

Какие характеристики машины, на которой всё это работать будет?

Это сообщение отредактировал(а) Дрон - 19.4.2005, 12:11

Не а как тут без динамики?

Цитата

А если просто выделить сразу 8*3 = 24 Метра, это ж не так уж и много smile

, чето плохо

А что с ними потом делается? (с данными)

Дрон
Ну, под выделить я понимаю, не malloc или new, а VirtualAlloc и всё такое. Можно сначала зарезервировать 24 метра, потом их коммитить по мере надобности.

Если принимаешь TCP пакетами, то они <1500 байт. Следовательно можно создать вектор, в который пихать эти пакеты, т.е. мегабайты. Ну а там уж сортировать.
А что такого страшного в выделении? В винде 4Гига виртуального адресного пространства доступно. Так, что 8 метров это мизер

Step, а чём тебя пугает автоматическое выделение? Вроде ж немного жрёт процессора.
В программировании всегда так, или экономичность или скорость.

24 метра на стартовом этапе это много.....

программа идет у меня как дипломный проект и должна работать везде и всюду под видной пусть там даже 32 метра с 95 виндой, загвоздка в том что 8 метров сейчас - это месячные данные измерения - с заменой некоторых элементов вполне вероятно что будет по 4 метра в день новых данных а в особых случаях 500 кил новых данных в течении пары минут частота таких случаев не велика но все же. Все остальное время программа постоянно обновляет данные размером 20 кил.
что бы было понятно обясню, что значит постоянно
1. запрос
2. ответ в буфер
3. опять запрос и одновременное обработка буфера с удалением буфера
4. ответ в новый буфер
5. на 3.

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

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


зы: понимаю что если это дипломная то я слишком серьезно отношусь - отвечаю вопервых это магистратура, во вторых за эту прогу мне еще и денег отвалят, в третьих для меня будет зарезервированно одно рабочее место с неплохой стартовой зарплатой
Добавлено @ 08:47
chipset, врядли оно сможет отследить некоторые неприятные особенности с которыми в один прекрасный момент могут прийти данные
Дрон, как вариант, но это много...
bel_nikita, данные на винт попасть не должны, да идет через тсп/ип

Цитата

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

насколько я понял, это относится ко второму режиму работы (когда данные принимаются кусочками по 20К)?
что касается первого режима, я вижу два варианта:
1. не запрашивать сразу все 24М, а обрабатывать по частям (например по 20К)
2. архивировать данные (я не знаю, что такое хмлрпц, но если это основано на XML, то, по идее, сжиматься должно неплохо(на одном словарном кодировании тегов и выделении одного символа для закрывающего тега можно неплохо сжать))
Добавлено @ 10:24
а вообще не помешало бы рассказать про задачу чуть-чуть больше (если, конечно, ситуация позволяет)

Если прием/передача идет на уровне tcp/ip пакетов, то ...
Завести треды на прием tcp пакетов, второй обработку результатов. Поставь приоритет real-time. Я так понял, это будет нечто клиен-сервер, т.е. с установкой соединения, а значит данные можно черпать по мере необходимости и обрабатывать. Как бы нибыло, но данные приходящие по сетке все равно кладутся по DMA в буфер.
Один тред отвечает за прием данных и кладет их в циклический буфер. Второй тред извлекает данные из буффера и обрабатывает. Вроде хорошее быстродействие получишь

З.Ы.: вообще-то надо начинать с того, чтобы узнать, как отсылающая сторона посылает эти данные? И на основе этого уже подстраиваться. Что представляет собой принятый tcp пакет, т.е. что в этих 1500 байтах будет содержаться? Смысловая информация или просто кусок буфера?

тред это поток или, что

забудьте по блоковую обработку это не возможно в виду сложности и величины структуры


ладно буду играться с динамикой




maxim1000, основной режим работает постоянно, просто к ниму изредка добовляються еще пару режимов

Цитата

моя программа получает по сети данные размер которых порядка 4 Метров и таких данных может одновременно приходить до 3 штук

ну хотя бы на эти 3 штуки разделить можно?

Цитата

основной режим работает постоянно

основной - это который маленькими кусочками?

и кстати, что за формат? XML?

Это сообщение отредактировал(а) maxim1000 - 20.4.2005, 13:28

maxim1000, как ни крути а придется с динамикой играться причем очень осторожно


xmlrpc введи в яндексе "xml rpc структура"

Цитата(Step @ 20.4.2005, 11:36)

maxim1000, как ни крути а придется с динамикой играться причем очень осторожно

это очевидно
просто сжатие позволит играться посвободнее

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