делал ли ктото приложения под венды в которых юзер имел один процесс с гуи который взаимодестовал с другим процессом без гуя
и когда пользователь делал операцию какюуто в гуе, первый процесс связаывлся со вторым поулчал какито данные назад, которые сразу же отображались в гуе первого процесса
это все понятно дело делаолось через какойто интероп
мне интересно тут насколько вот быстро этот виндовский интероп работает, если нет операций с диском или сетью, то вот этот запрос-ответ будет происходить достаточно быстро чтобы юзер не почустовал никакого дископмфорта? наскока можно сделать это плавным?
с одной стороны мне кажется что мои опасения напрасны учитывая скорости совренеых цпу, с другой стороны в системе может быть много потоков и как там планировщик работает тоже неизвестно
и кста как на этот вопрос влияет мультиядерность?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>мне интересно тут насколько вот быстро этот виндовский интероп работает, если нет операций с диском или сетью, то вот этот запрос-ответ будет происходить достаточно быстро чтобы юзер не почустовал никакого дископмфорта? наскока можно сделать это плавным?
А вы откройте гуглохром или файрфокс, поработайте в них. Там тот самый интероп, всё очень шустрое.
Здравствуйте, Barbar1an, Вы писали:
B>мне интересно тут насколько вот быстро этот виндовский интероп работает, если нет операций с диском или сетью, то вот этот запрос-ответ будет происходить достаточно быстро чтобы юзер не почустовал никакого дископмфорта? наскока можно сделать это плавным?
Чтобы юзер не почуствовал никакого дискомфорта, у тебя есть десятки миллисекунд. Это очень большое время, любой виндовсный механизм IPC сам по себе достаточно быст для этой цели.
B>с одной стороны мне кажется что мои опасения напрасны учитывая скорости совренеых цпу, с другой стороны в системе может быть много потоков и как там планировщик работает тоже неизвестно
Достаточно давно (во времена XP и одноядерных машин) у меня была задача, заключавшаяся в том, что моя программа принимает из сети видеопоток, а другой процесс его визуализирует.
Программе, которая занималась сетью, не нужно было много CPU, но ей не нравилось, если CPU у нее отнимают слишком надолго. Выяснилось, что активная экранная деятельность может отнять у всех процессор на сотни миллисекунд. Проблема решилась повышением приоритета соответствующего потока.
Кстати интересно, что линуксная версия той же самой программы на сравнимой по мощности машинке работала абсолютно гладко без всех этих ухищрений.
Pzz>Программе, которая занималась сетью, не нужно было много CPU, но ей не нравилось, если CPU у нее отнимают слишком надолго. Выяснилось, что активная экранная деятельность может отнять у всех процессор на сотни миллисекунд. Проблема решилась повышением приоритета соответствующего потока.
Погадаю: видеопоток прилетал по UDP, а увеличить ассоциированный с сокетом буфери приема setsockopt(..SO_RCVBUF... никто не догадался.
Pzz>Кстати интересно, что линуксная версия той же самой программы на сравнимой по мощности машинке работала абсолютно гладко без всех этих ухищрений.
А в линуксе наверное буфер по дефолту пожирней.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Погадаю: видеопоток прилетал по UDP, а увеличить ассоциированный с сокетом буфери приема setsockopt(..SO_RCVBUF... никто не догадался.
Не угадал
Pzz>>Кстати интересно, что линуксная версия той же самой программы на сравнимой по мощности машинке работала абсолютно гладко без всех этих ухищрений. O>А в линуксе наверное буфер по дефолту пожирней.
