>Тормозит шарик ровно потому что внутрях сидит код на C++
>А это работает парсер-генератор, который все контролы ascx компилирует при поднятии пула. Причем сам парсер-генератор написан на C++.
Может быть…
>А в 2013 версии еще подключичи Distributed Cache, который имеет ядро на C++ и которомоу потребовалось три патча, чтобы поправить все учтечки памяти.
Вот кстати часть исключений точно была с ним связана, правда происходили они в managed коде, но это могла быть и обертка. Кэш у меня не был настроен (его вообще обязательно настраивать?)
>Почти каждая самописная система с таким функционалом, которую я видел, валилась уже на пяти запросах.
А есть ли примеры более менее известных, для сравнения?
>А думаешь FileStream.Read делает что-то сильно другое?
Нет, не сильно, просто машинного кода в нем будет исполнено больше во время этого вызова
>Думаешь в STL обвязок меньше? Или ты под каждую платформу свои нативные методы вызываешь в кроссплатформенном языке?
В простом чтении из файла обвязок меньше. Еще меньше обвязок в вполне кросплатформенном fread.
Но конкретно IOCP в STL нет.
Возможно только в Boost.Asio будет что-то подобное.
Я думаю IOCP лучше прописать под каждую платформу, т.к. IOCP платформо-зависимая фича, которая в таком виде есть только в Windows, на других платформах есть схожие, но другие фичи.
Опять таки, реализация IOCP в Mono будет совсем другой и по всей видимости обернута еще большим количеством кода.
>Короче не думай что ты умнее людей, которые писали .NET, особенно BCL. Это не так с вероятностью 100%.
Я не спорю, конкретно BCL — действительно хорошо написан, но часто он решает более общую задачу чем требуется, что будет всегда немного отжирать дополнительного времени в рантайме.
>Как вы добавляли элементы? Просто datagrid.ItemsSource = somelist?
да
>Что было внутри того контрола numericupdown смотрели?
Профайлер непосредственно этот контрол не дергал. В каком смысле что внутри?
>Measure у какого элемента дергался и после чего?
Больше всего времяни было кажется в базовой реализации Measure, могу уже не помнить
>Если фреймворк был >= 4.5, то какой стоял VirtualizationMode?
Все варианты VirtualizationMode были точно испробованы на 4.0 фреймворке.
На машинах с 4.5 это тоже не помогало. Специфичные только 4.5 режимы не использовались, т.к. нужна была поддержка 4.0
По вашему примеру, важно как минимум поменять:
1. Колонки должны быть не автогенеренные, а явно прописанные в xaml с указанным размером
2. Их должно быть хотябы 10 штук
3. Часть из них, доблжы быть типа datagridtemplatecolumn, c Combobox внутри
4. Колонки должны быть забинжены на данные
5. В гиде должны быть разрешены редактирование и сортировка
— возможно этого минимума хватить чтобы воспроизвести проблему
Можно еще добавить (хотя и не обязательно, и наверное не стоит вам тратить на это время):
1. Визуальные стили на лист
2. Конвертеры в биндинге
3. В идеале добавить datagridtemplatecolumn с datetime picker и numericupdown из codeplex
4. В datagridtemplatecolumn использовать разные темплейты для редактирования и просмотра.
Пример в проекте, который я некоторое время не видел, попробую найти его и на его основе него сделать хеловорд, как будет время
>Ну, во-первых, нет, completion routine — это не IOCP (что, кстати, показывает, что вы с этим не работали).
C IOCP я и правда не работал — необходимости в этом не было… видимо имеется ввиду это
msdn.microsoft.com/ru-ru/library/windows/desktop/aa363862(v=vs.85).aspx
>А во-вторых, каково количество прыжков и ужимок, которое мне на это понадобится, по сравнению с простым async/await-кодом в C#?
Это уж вопрос к тому насколько вам принципиально написать этот кусок (чуть?) быстрее. Безусловно прыжков и ужимок будет больше, но это будут ваши прыжки и ужимки, о которых вы точно будете знать что они делают, а не прыжки и ужимки дотнета.
>Если время выполнения обработчика чанка будет значительно меньше времени чтения следующего чанка с диска, то общее время обработки будет лишь слегка превышать общее время чтения
Я имел ввиду количество вызовов необходимых для инициализации чтения чанка.
Вообще то нет. Всетаки пока лучше придерживаться С++0х, (С++11), чтобы не попасть на то, что на одной платформе в компиляторе реализовали одни новые фичи, а на другой реализовали другие.
Хотя когда подтянутся — вполне можно и С++14 и может даже С++17
Кроме грида на форме ничего не было, поэтому дерево только грида.
Measure дергается по всей видимости для ячеек грида в ответ на попытку скролить содержимое.
Это стандартный датагрид WPF.
(C DevExpress отдельные проблемы)
Telerik вполне возможно работает лучше — не знаю — не пробовал…
Честно говоря ничего особенного не делал с ним.
Единственное, когда я аттачился к нему дебагером, он периодический(хотя и не так часто) handled валился с какойто ошибкой аутентификации, толи ферму искал и не находил, толи еще что-то — уже не помню точно.
Может дело в конфигурации, но она у меня была дефолтная standalone, машина была в домене…
Может он и правда постоянно в фоне подваливался чем тормозил любые обработки, но врядли на столько. Еще создавалось ощущение что дольше чем надо подфисает на WCF коммуникациях между своими компонентами (дебажил его под рефлектором, поэтому код его видел — т.к. большая часть шарепоинта .net)… опять таки — незнаю почему…
С++ будет работать через меньшее количество прослоек, как с I/O так и с памятью, куда это I/O положит данные, это может помочь.
ReadFileEx например можно вызывать и из C# по
[DllImport(«kernel32.dll»)]
static extern bool ReadFileEx(IntPtr hFile, [Out] byte [] lpBuffer,
uint nNumberOfBytesToRead, [In] ref System.Threading.NativeOverlapped lpOverlapped,
ReadFileCompletionDelegate lpCompletionRoutine);
Но я честно говоря не уверен что byte [] lpBuffer отмаршалится без дополнительных издержек.
А нативные стримы С# до ReadFileEx идут через несколько оберток, чтобы убедиться — возмите рефлектор и посмотрите на реализацию System.IO.FileStream.Read, там давольно много возможно лишнего для вашего случая кода, до того как вызывается
[DllImport(«kernel32.dll», SetLastError=true)]
internal static extern unsafe int ReadFile(SafeFileHandle handle, byte* bytes, int numBytesToRead, IntPtr numBytesRead_mustBeZero, NativeOverlapped* overlapped);
Вы сможете сделать это вызов без выполнения этого кода, кроме того вы возможно сможете избежать вызова
Buffer.InternalBlockCopy(this._buffer, this._readPos, array, offset, byteCount);
в System.IO.FileStream.Read
Я незнаю сколько именно это добавит производительности в процентах, но точно знаю что прочитать файл на С++ можно меньшим количеством исполняемого машинного кода, чем будет выполнено в System.IO.FileStream.Read
Да тут собственно и дерева то нет. Я же говорю, только обычный родной WPF датагрид. В нем штук 10 колонок, некоторые из них на основе DataTemplate c одним простым контролом (комбобоксом или datetime picker или numericupdown из codeplex) внутри, остальные колонки стандартные.
Из своего кода только установка ItemSource обычным листом из 1000-2000 элементов и xaml разметка.
И вот этого уже хватает чтобы контрол скролился с сильными лагами, а в профайлере были многочисленные вызовы Measure.
Код смотрели многократно — нету там ничего особенного.
Такие задачи тоже бывают конечно, в основном при обработке сырых данных.
Кстати, если вы не выжимаете предельную скорость из вашего HDD, то С++ думаю помог бы ее выжать. А если выжимаете и так, то тут либо другое железо поможет, либо читать можно какнибудь с уровнем детализации «через кадр» (в несжатом стриме наверное достаточно просто пропустить кадр или несколько и добрать их когда они будут очень нужны)
Спасибо конечно, но эти фиксы не помогают. Проблема с вызовом UIElement.Measure вылезает даже на последних версиях фреймворка, где все фиксы уже включены.
Вероятно что то недофиксили и забили, как это принято в Microsoft :(
>И мы будем ограничены в скорости сразу двух I/O, круто.
Я не вижу вашей задачи полностью. Но если I/O камеры заметно быстрее чем I/O диска, то при надлежащем сжатии(если мы его потянем по cpu) мы будет ограничены только I/O камеры, так как количество данных для записи на диск станет многократно меньше и его I/O с этим легко справится.
И это разумеется позволит работать быстрее чем с диском.
Но все это только в случае если I/O действительно быстрее I/O диска.
>Да какая разница, окупится ли он, достаточно того, что все равно скорость работы будет ограничена скоростью I/O, а не вычислений.
Да, разумеется, но в этой задаче, и вычислений то особых нет, тут в основном только I/O и выполняется…
>Что камера отдала, с тем и работаем.
можно попробовать брать поток в память прямо с камеры по USB\Firewire (или как она подключается), сжимать и уже потом класть на диск…
>Есть-то есть, только индекс (а) тоже надо построить, это время и (б) он все равно будет ограничивающим фактором по скорости.
Индекс конечно решение неоднозначное. Если сканирование нужно проводить всегда для разных множеств фотографий — то лучше наверное просто взять SSD и все.
А если надо многократно сканировать надо одни и теже фотографии, которые могут немного меняться, то индекс должен бы окупиться, если правильно прописать его обновление.
>Какими «другими»?
Думаю затратами на железо, энергию и место где все это железо находится.
>Это просто как иллюстрация границ применимости вашего поста и выводов в нем.
Да. Но это на данный момент, особый интерес представляет как развитие пойдет дальше. В железе наметилась стагнация, к чему она нас приведет?
А, кстати о инфраструктуре на C#, например Sharepoint 2013
Написан на C#, но как-же он тормозит…
На машине с 24Gb памяти и SSD на гигабитной локальной сетке ПУСТАЯ страничка с его сайта открывается секунд 5. А на холодную так вообще минуту ждать можно.
Конечно ему рекомендована ферма, а машина с 24 гигами это что-то вроде минималки, но мне сложно представить, зачем для решаемых им задач столько ресурсов…
Думаю в вебе высокую нагрузку пока побеждают другими способами и эти способы пока окупаются, не знаю как долго такая ситуация сохранится. Возможно достаточно долго.
Если говорить об областях где без С++ никак
Однозначно С++ нужен в CAD отрасли пока все кады которые мне попадались имели С++-ный рендер, и С++- ную модель данных, по сути на .net были только элементы UI.
В задачах решаемых продуктами Adobe, C++ очень уместен. Во превых потомучто продукты собираются примерно из одних исходников как минимум под MacOS и Windows, а во вторых потомучто производительность и отвывчивость UI там имеет большое значение, это как никак рабочие инструменты.
Конечно в топовых 3D играх с достаточно сложными моделями и графикой. Ни одной такой на .net не попадалось.
В реализации нектороых сервисов по обработке файлов ряда форматов.
Банально, но в разработке операционных систем.
В разработке встраимого ПО, там как правило и вариантов других нет.
Я думаю можно найти и другие отрасли, но это состояние потребностей на данный момент, вопрос как оно изменится в перспективе…
> внезапно выясняется, что asp.net в частности и .net вообще тут ни при чем,
Не совсем, на сколько я понял, asp.net был одной из немногих технологий позволявших завязаться на IE на столько сильно. Хотя конечно, никто не заставлял использовать такие его «приемущества», но видимо из-за них asp.net и был выбран.
> Так что конкретно эта судьба могла бы постигнуть любую (подчеркиваю, любую) серверную платформу. А конкретный C++, как вы же признались, для веба еще и не подходит…
Я ни где и не рекомендовал использовать С++ для веба. Однако, если бы эти проекты были реализованы ввиде клиентов и сервера например на С++, а не в виде интернет приложений, то они имели бы намного больше шансов ожить на мобильных платформах в виде отдельных приложений.
Другое дело, что это абсолютно другая ветка развития и в крайне сослагательном наклонении.
>А это работает парсер-генератор, который все контролы ascx компилирует при поднятии пула. Причем сам парсер-генератор написан на C++.
Может быть…
>А в 2013 версии еще подключичи Distributed Cache, который имеет ядро на C++ и которомоу потребовалось три патча, чтобы поправить все учтечки памяти.
Вот кстати часть исключений точно была с ним связана, правда происходили они в managed коде, но это могла быть и обертка. Кэш у меня не был настроен (его вообще обязательно настраивать?)
>Почти каждая самописная система с таким функционалом, которую я видел, валилась уже на пяти запросах.
А есть ли примеры более менее известных, для сравнения?
Нет, не сильно, просто машинного кода в нем будет исполнено больше во время этого вызова
>Думаешь в STL обвязок меньше? Или ты под каждую платформу свои нативные методы вызываешь в кроссплатформенном языке?
В простом чтении из файла обвязок меньше. Еще меньше обвязок в вполне кросплатформенном fread.
Но конкретно IOCP в STL нет.
Возможно только в Boost.Asio будет что-то подобное.
Я думаю IOCP лучше прописать под каждую платформу, т.к. IOCP платформо-зависимая фича, которая в таком виде есть только в Windows, на других платформах есть схожие, но другие фичи.
Опять таки, реализация IOCP в Mono будет совсем другой и по всей видимости обернута еще большим количеством кода.
>Короче не думай что ты умнее людей, которые писали .NET, особенно BCL. Это не так с вероятностью 100%.
Я не спорю, конкретно BCL — действительно хорошо написан, но часто он решает более общую задачу чем требуется, что будет всегда немного отжирать дополнительного времени в рантайме.
>Какая точно была версия фремворка?
4.0 и 4.5
>Как вы добавляли элементы? Просто datagrid.ItemsSource = somelist?
да
>Что было внутри того контрола numericupdown смотрели?
Профайлер непосредственно этот контрол не дергал. В каком смысле что внутри?
>Measure у какого элемента дергался и после чего?
Больше всего времяни было кажется в базовой реализации Measure, могу уже не помнить
>Если фреймворк был >= 4.5, то какой стоял VirtualizationMode?
Все варианты VirtualizationMode были точно испробованы на 4.0 фреймворке.
На машинах с 4.5 это тоже не помогало. Специфичные только 4.5 режимы не использовались, т.к. нужна была поддержка 4.0
По вашему примеру, важно как минимум поменять:
1. Колонки должны быть не автогенеренные, а явно прописанные в xaml с указанным размером
2. Их должно быть хотябы 10 штук
3. Часть из них, доблжы быть типа datagridtemplatecolumn, c Combobox внутри
4. Колонки должны быть забинжены на данные
5. В гиде должны быть разрешены редактирование и сортировка
— возможно этого минимума хватить чтобы воспроизвести проблему
Можно еще добавить (хотя и не обязательно, и наверное не стоит вам тратить на это время):
1. Визуальные стили на лист
2. Конвертеры в биндинге
3. В идеале добавить datagridtemplatecolumn с datetime picker и numericupdown из codeplex
4. В datagridtemplatecolumn использовать разные темплейты для редактирования и просмотра.
Пример в проекте, который я некоторое время не видел, попробую найти его и на его основе него сделать хеловорд, как будет время
C IOCP я и правда не работал — необходимости в этом не было… видимо имеется ввиду это
msdn.microsoft.com/ru-ru/library/windows/desktop/aa363862(v=vs.85).aspx
>А во-вторых, каково количество прыжков и ужимок, которое мне на это понадобится, по сравнению с простым async/await-кодом в C#?
Это уж вопрос к тому насколько вам принципиально написать этот кусок (чуть?) быстрее. Безусловно прыжков и ужимок будет больше, но это будут ваши прыжки и ужимки, о которых вы точно будете знать что они делают, а не прыжки и ужимки дотнета.
>Если время выполнения обработчика чанка будет значительно меньше времени чтения следующего чанка с диска, то общее время обработки будет лишь слегка превышать общее время чтения
Я имел ввиду количество вызовов необходимых для инициализации чтения чанка.
Хотя когда подтянутся — вполне можно и С++14 и может даже С++17
msdn.microsoft.com/ru-ru/library/windows/desktop/aa365468(v=vs.85).aspx
Что, как я понимаю, тоже позволит активировать ваш обработчик.
На счет доли производительности… Смотря как часто этот код выполняется, чем чаще, тем больше будет доля…
Measure дергается по всей видимости для ячеек грида в ответ на попытку скролить содержимое.
Это стандартный датагрид WPF.
(C DevExpress отдельные проблемы)
Telerik вполне возможно работает лучше — не знаю — не пробовал…
А с шарепоинтом я и правда не много имел опыта, поэтому возможно дело в неправильной конфигурации.
Единственное, когда я аттачился к нему дебагером, он периодический(хотя и не так часто) handled валился с какойто ошибкой аутентификации, толи ферму искал и не находил, толи еще что-то — уже не помню точно.
Может дело в конфигурации, но она у меня была дефолтная standalone, машина была в домене…
Может он и правда постоянно в фоне подваливался чем тормозил любые обработки, но врядли на столько. Еще создавалось ощущение что дольше чем надо подфисает на WCF коммуникациях между своими компонентами (дебажил его под рефлектором, поэтому код его видел — т.к. большая часть шарепоинта .net)… опять таки — незнаю почему…
ReadFileEx например можно вызывать и из C# по
[DllImport(«kernel32.dll»)]
static extern bool ReadFileEx(IntPtr hFile, [Out] byte [] lpBuffer,
uint nNumberOfBytesToRead, [In] ref System.Threading.NativeOverlapped lpOverlapped,
ReadFileCompletionDelegate lpCompletionRoutine);
Но я честно говоря не уверен что byte [] lpBuffer отмаршалится без дополнительных издержек.
А нативные стримы С# до ReadFileEx идут через несколько оберток, чтобы убедиться — возмите рефлектор и посмотрите на реализацию System.IO.FileStream.Read, там давольно много возможно лишнего для вашего случая кода, до того как вызывается
[DllImport(«kernel32.dll», SetLastError=true)]
internal static extern unsafe int ReadFile(SafeFileHandle handle, byte* bytes, int numBytesToRead, IntPtr numBytesRead_mustBeZero, NativeOverlapped* overlapped);
Вы сможете сделать это вызов без выполнения этого кода, кроме того вы возможно сможете избежать вызова
Buffer.InternalBlockCopy(this._buffer, this._readPos, array, offset, byteCount);
в System.IO.FileStream.Read
Я незнаю сколько именно это добавит производительности в процентах, но точно знаю что прочитать файл на С++ можно меньшим количеством исполняемого машинного кода, чем будет выполнено в System.IO.FileStream.Read
Из своего кода только установка ItemSource обычным листом из 1000-2000 элементов и xaml разметка.
И вот этого уже хватает чтобы контрол скролился с сильными лагами, а в профайлере были многочисленные вызовы Measure.
Код смотрели многократно — нету там ничего особенного.
Кстати, если вы не выжимаете предельную скорость из вашего HDD, то С++ думаю помог бы ее выжать. А если выжимаете и так, то тут либо другое железо поможет, либо читать можно какнибудь с уровнем детализации «через кадр» (в несжатом стриме наверное достаточно просто пропустить кадр или несколько и добрать их когда они будут очень нужны)
Вероятно что то недофиксили и забили, как это принято в Microsoft :(
Я не вижу вашей задачи полностью. Но если I/O камеры заметно быстрее чем I/O диска, то при надлежащем сжатии(если мы его потянем по cpu) мы будет ограничены только I/O камеры, так как количество данных для записи на диск станет многократно меньше и его I/O с этим легко справится.
И это разумеется позволит работать быстрее чем с диском.
Но все это только в случае если I/O действительно быстрее I/O диска.
>Да какая разница, окупится ли он, достаточно того, что все равно скорость работы будет ограничена скоростью I/O, а не вычислений.
Да, разумеется, но в этой задаче, и вычислений то особых нет, тут в основном только I/O и выполняется…
можно попробовать брать поток в память прямо с камеры по USB\Firewire (или как она подключается), сжимать и уже потом класть на диск…
>Есть-то есть, только индекс (а) тоже надо построить, это время и (б) он все равно будет ограничивающим фактором по скорости.
Индекс конечно решение неоднозначное. Если сканирование нужно проводить всегда для разных множеств фотографий — то лучше наверное просто взять SSD и все.
А если надо многократно сканировать надо одни и теже фотографии, которые могут немного меняться, то индекс должен бы окупиться, если правильно прописать его обновление.
Да ладно вам. В С# вполне есть себе goto, просто им не пользуются.
msdn.microsoft.com/ru-ru/library/13940fs2.aspx
Добавтить ворнинг и в С++ пользоваться не будут :)
Думаю затратами на железо, энергию и место где все это железо находится.
>Это просто как иллюстрация границ применимости вашего поста и выводов в нем.
Да. Но это на данный момент, особый интерес представляет как развитие пойдет дальше. В железе наметилась стагнация, к чему она нас приведет?
Написан на C#, но как-же он тормозит…
На машине с 24Gb памяти и SSD на гигабитной локальной сетке ПУСТАЯ страничка с его сайта открывается секунд 5. А на холодную так вообще минуту ждать можно.
Конечно ему рекомендована ферма, а машина с 24 гигами это что-то вроде минималки, но мне сложно представить, зачем для решаемых им задач столько ресурсов…
Если говорить об областях где без С++ никак
Однозначно С++ нужен в CAD отрасли пока все кады которые мне попадались имели С++-ный рендер, и С++- ную модель данных, по сути на .net были только элементы UI.
В задачах решаемых продуктами Adobe, C++ очень уместен. Во превых потомучто продукты собираются примерно из одних исходников как минимум под MacOS и Windows, а во вторых потомучто производительность и отвывчивость UI там имеет большое значение, это как никак рабочие инструменты.
Конечно в топовых 3D играх с достаточно сложными моделями и графикой. Ни одной такой на .net не попадалось.
В реализации нектороых сервисов по обработке файлов ряда форматов.
Банально, но в разработке операционных систем.
В разработке встраимого ПО, там как правило и вариантов других нет.
Я думаю можно найти и другие отрасли, но это состояние потребностей на данный момент, вопрос как оно изменится в перспективе…
Не совсем, на сколько я понял, asp.net был одной из немногих технологий позволявших завязаться на IE на столько сильно. Хотя конечно, никто не заставлял использовать такие его «приемущества», но видимо из-за них asp.net и был выбран.
> Так что конкретно эта судьба могла бы постигнуть любую (подчеркиваю, любую) серверную платформу. А конкретный C++, как вы же признались, для веба еще и не подходит…
Я ни где и не рекомендовал использовать С++ для веба. Однако, если бы эти проекты были реализованы ввиде клиентов и сервера например на С++, а не в виде интернет приложений, то они имели бы намного больше шансов ожить на мобильных платформах в виде отдельных приложений.
Другое дело, что это абсолютно другая ветка развития и в крайне сослагательном наклонении.