mike mikeAntoshkaПробовал просто зарядить в грид 20 тыс. записей - тормоза при открытии и скролле. Тот же набор данных паралельно на VCL'ной ExpressQuantumGrid работает вообще без вопросов. Куда копать, где эта хвалёная скорость WPF-интерфейса.

WPF практически всегда будет медленнее, чем vcl/winforms.
За дополнительные возможности к сожалению надо платить :)

Ну а насчет проблем в данном конкетном случае, скорее всего они решаемы, если нет чрезмерно сложных темплейтов.
стоит написать на support.devexpress.com с примером.

p.s. я учавствовал в разработке этого грида, и посмотрю чтобы ответ на вопрос был максимально быстрым
pps. если запостите вопрос на support, желательно прислать мне id вопроса, чтобы он точно дошел до разработчика.

То, что winforms быстрее wpf - полная чушь. Посмотрите гриды других фирм.На каком-то форуме(кажется, самих девок) читал высказывание, что DevExpress ничего не смыслет в wpf, выводы были сделаны после звонка в техподдрержку, несли поную околесицу и бред

mike mikei
То, что winforms быстрее wpf - полная чушь. Посмотрите гриды других фирм.На каком-то форуме(кажется, самих девок) читал высказывание, что DevExpress ничего не смыслет в wpf, выводы были сделаны после звонка в техподдрержку, несли поную околесицу и бред

Люблю читать такие посты. Просто и безапелляционно:)
1) у DevExpress нет техподдержки по телефону. Есть только sales.
2) если на заборе кто-то, что-то и написал - то это абсолютно не значит, что за забором что-то лежит :)
3) практически любой (кроме телерика :) )Winforms грид, будет всегда быстрее абсолютно любого WPF грида при одинаковом числе видимых колонок и столбцов.
Гарантировано будет быстрее в разы (>3 раз) при первоначальном показе и от 50% быстрее при скроллинге.

Посморти контролы других разработчиков . Ваши winforms - беременные девки по сравнению с ними. Не ищите оправдание своей криворукости.
PS Самое инетересное в xaml - то, что все ваши платные приблуды совершенно не нужны.

mike mikeкстати, целью появляния здесь, было не желание поспорить о плюсах или минусах win/wpf - а желание разобраться в проблема того, что начал это обсуждение.....
Вот и разбирался бы с проблемами, а не рассказывал сказки.

mike mikeimike mikei
То, что winforms быстрее wpf - полная чушь. Посмотрите гриды других фирм.На каком-то форуме(кажется, самих девок) читал высказывание, что DevExpress ничего не смыслет в wpf, выводы были сделаны после звонка в техподдрержку, несли поную околесицу и бред

Люблю читать такие посты. Просто и безапелляционно:)
1) у DevExpress нет техподдержки по телефону. Есть только sales.
2) если на заборе кто-то, что-то и написал - то это абсолютно не значит, что за забором что-то лежит :)
3) практически любой (кроме телерика :) )Winforms грид, будет всегда быстрее абсолютно любого WPF грида при одинаковом числе видимых колонок и столбцов.
Гарантировано будет быстрее в разы (>3 раз) при первоначальном показе и от 50% быстрее при скроллинге.

Посморти контролы других разработчиков . Ваши winforms - беременные девки по сравнению с ними. Не ищите оправдание своей криворукости.
PS Самое инетересное в xaml - то, что все ваши платные приблуды совершенно не нужны.

Ну и что данная демка показывает?
Кроме того, что они специально отвели лишь 1/2 высоты экрана под реальный grid, а остальное под раздутое описание? ;-)

Реальная производительность xceed'a видна на их "classic table view". И кстати, она достаточна средняя (или даже ниже), учитывая даже то, что они "сразают" углы :) - и те же grid lines у них, я вляются не объектами - и просто нарисованными линиями.

Ну а то, что они эмулируют быструю производительность в "Table flow" - это достаточно своеобразный подход, который имеет весьма много минусов.

А насчет того, что в "Xaml" никакие тулзы не нужны, это весьма спорное утверждение.
Зачастую, достаточно попытаться темировать combobox, чтобы понять, что книжки по WPF и реальность - это две большие разницы.
Кому нужны ваши объекты для линий? С шаблонами xaml, ваши навороты - все равно бледное подобие.
ЧТо 1/2, что весь экран разницы в быстродействии не будет никакой. В отличии от вас у них полная UI виртуализация.
Ваши девки просто уйдут в даун при нескольких сотнях тысячах записей(была одна блажь у заказчика, до 500К через две минуты данные появлялись, если больше - миссия не выполнима, только одним столбцом). Попробуй загрузить в свои красавицы, как в примере, 10M записей на 500 столбцов.

МСУiСамое инетересное в xaml - то, что все ваши платные приблуды совершенно не нужны.
iВ отличии от вас у них полная UI виртуализация... бла-бла ...



P.S. То на левый берег, то на правый. А-ля, пьяный карабель )
Мусичка, для тебя, что wpf,что виртуализации - все пустые звуки. Я дал ссылку на готовый пример, если кто-то работал с winforms, то и так будет сразу все понятно с быстродействием.
Ты у нас - особый случай, вот и развлекайся сам. Будет отличный способ себя занять и поболоболить здесь

mike mikeiКому нужны ваши объекты для линий? С шаблонами xaml, ваши навороты - все равно бледное подобие.
ЧТо 1/2, что весь экран разницы в быстродействии не будет никакой. В отличии от вас у них полная UI виртуализация.
Ваши девки просто уйдут в даун при нескольких сотнях тысячах записей(была одна блажь у заказчика, до 500К через две минуты данные появлялись, если больше - миссия не выполнима, только одним столбцом). Попробуй загрузить в свои красавицы, как в примере, 10M записей на 500 столбцов.

demos.devexpress.com/DXGridDemos/
демка называется "Large DataSet". Находится в Highlighted features.
Выбираешь там 10m записей и 10000 столбцов.

Ну при желании, можно и 250 стобцов выбрать ;-)
А причем здесь wpf, ранее утверждалось, что winforms впереди планеты всей. Но таких тесты никому не нужны(и так все знают). Одна из причин перехода на wpf - скорость, которая старью и не снилась

mike mikei
Ну при желании, можно и 250 стобцов выбрать ;-)
А причем здесь wpf, ранее утверждалось, что winforms впереди планеты всей. Но таких тесты никому не нужны(и так все знают). Одна из причин перехода на wpf - скорость, которая старью и не снилась

Кто-то несколькими постами выше утверждал, что dx wpf тормозной фуфел? ;-)

хочется winforms, пожалуйста.
Качаем trial, запускаем GridTutorials - VirtualData - выбираем нужное число записей и столбцов - и смотрим.[/quot]
Уже есть вариант проще - качаем триал нормального грида wpf, подключаем данные без всяких бубнов, тк виртуализация уже есть, после этого забываем о winforms и DevExpress

mike mike.i
Уже есть вариант проще - качаем триал нормального грида wpf, подключаем данные без всяких бубнов, тк виртуализация уже есть, после этого забываем о winforms и DevExpress

мда. Умных слов много, а значения их не понимаем. бывает.

Тро́ллинг (от англ. trolling — блеснение, ловля рыбы на блесну) — размещение в Интернете (на форумах, в дискуссионных группах, в вики-проектах, ЖЖ и др.) провокационных сообщений с целью вызвать флейм, конфликты между участниками, взаимные оскорбления и т. п. Лицо, занимающееся троллингом, называют троллем, что совпадает с названием мифологического существа.

mike, cамокритичность - замечательная черта. Нечасто встретишь на этом форуме.

МСУimike, cамокритичность - замечательная черта. Нечасто встретишь на этом форуме.
... сказал гуест под левым серым ником и щиманулся в кусты.

+

Писнул, кроличек, и уныло побрел в тупик с кувалдометром

писнул - пискнул

Как всегда не угадал, Мусичка. Просто общаться с тобой - одно удовольствие.
Можно еще раз прильнуть к такому кладезю знаний.

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

МСУ, бросай свое кайло, срочно "кури" LightSwitch, а то не чувствуется больше твоего пионерского задора. Видно, совсем ты утомился.

Роман Еремин (DevExpress)Asm64DНа правах высказывания в слух:
WPF у DevExpress в ж..е плохо работает и ужасен и их разработчики могут сколь угодно бить себя в грудь (здесь и на рсдн) уверяю что просто у всех остальных кривые руки. Ребята (разработчики) спуститись на землю и посчитайте сколько жалоб на ваше детеще и сделайте выводы.
Ну читаем и делаем выводы. С конкурентами сравниваем и пытаемся лучше сделать. Основная проблема в том, что после криков "все говно" редко следует конкретика из которой можно сделать выводы. Вот текущий топик взять - сказали что ужасающая скорость - а где, как, почему - не сказали. Наши демки показывают неплохую скорость. Стало быть мы либо какой-то сценарий не учли, либо человек что-то неоптимально настроил (это тоже может быть наш косяк в юзабилити). Но какие выводы может сделать разработчик? Никаких. Горько вздохнуть и пойти дальше работать.

Поэтому, если у вас, уважаемый Asm64D, есть что-то конкретное сказать, то призываю это сделать. Либо здесь, либо еще где - можно в личной переписке. Все конкретные претензии будут рассмотрены непосредственно разработчиками и руководством - глядишь мир и получше станет.
А какая нужна конкретика, если ваши разработчики, сами говорят, что WPF версия в три раза медленней, чем тугододумные Winforms?

mike mike
А вот контрол, которому для работы необходимо минимум создать ~(15 * 50 * 4) контрола, для того чтобы показать данные на экране, будет всегда медленее аналогичного, которому надо для этого сделать 15 * 50 * fillrectangle/drawtext.
Подобные объяснения с непонятными барабашками оставьте своему руководству. Ответы с подобным примитивизмом без учета особенностей движков, говорят не только о том, что DevExpress банально проспало WPF\SL, а у нее нет никаких перспектив. Вы и дальше будете кормить завтраками с обещаниями улучшить производительность. Год назад я даже не рассматривал ваши компоненты перед закупкой.
WPF\SL без ваших Winforms компонент работает минимум на два порядка быстрее. Это было одной из причин перехода.
Тесты для вас и вашего руководства

mike mikeimike mike
А вот контрол, которому для работы необходимо минимум создать ~(15 * 50 * 4) контрола, для того чтобы показать данные на экране, будет всегда медленее аналогичного, которому надо для этого сделать 15 * 50 * fillrectangle/drawtext.
Подобные объяснения с непонятными барабашками оставьте своему руководству. Ответы с подобным примитивизмом без учета особенностей движков, говорят не только о том, что DevExpress банально проспало WPF\SL, а у нее нет никаких перспектив. Вы и дальше будете кормить завтраками с обещаниями улучшить производительность. Год назад я даже не рассматривал ваши компоненты перед закупкой.
WPF\SL без ваших Winforms компонент работает минимум на два порядка быстрее. Это было одной из причин перехода.
Тесты для вас и вашего руководства

эээ. ссылка на французский блог, в котором сравнивают winforms компоненты, которые живут и работают через win32 API и просто физически не расчитаны на объемы > 10 записей, это верх изобретатильности :)

А не нужно ничего изобретать. Достаточно вспомнить, как величаво и плавно расправляли крылья формы с вашими компонентами на Winforms, и как все летает на уровне DOS в текстовом режиме сейчас на WPF.
Выложи тесты с вашими гридами, продемонстрируй на деле трехкратную разницу, а не рассказывай сказки.

ЗЫ У разработчиков контролов подобные тесты должны быть под рукой всегда с самого начала.
Особенно в сравнении с конкурентами.

mike mikebublikomРоман Еремин (DevExpress),

Состав формы Создание Загрузка
Пустая форма 30 50
Пустая форма с обычным гридом 50 60
Форма с LayoutControl 425 120
Форма с LayoutControl, LayoutGroup 800 600
Пустая форма с гридом DevExpress 900 900

Все мс.

Достаточно средняя форма загружается 3 секунды на E5300, 2.6 Мгц, 1.5 мб оперативки.
Я понимаю, конфигурация мягко говоря, не топовая, но чтоже будет на конечных рабочих станциях с селеронами 2.0 и памятью 1 гб ?

по тестам. некорректно мерять "load" формы.
сделал тестовое приложение, в котором в окне 1400x900 показывается грид, с 20колонками и 1000 записями.

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

dxgrid (2010.1)
xceed (2010.4) - tableview
datagrid (wpf framework)

winforms data grid
XtraGrid (2010.1)




Собственно, что эти цифры значат:
принимать во внимание стоит последнее число. Это время в миллисекундах, с момента
констуктора формы до момента ее реальной отрисовки.

Со стандартным гридом в wpf - тягаться не сможет вообще никто и никогда - по скорости первоначальной загрузки - так как ему не надо грузить темы и .dll - он уже в памяти.
но при дальнейшей работе приложения - его можно будет догонять.

по dx winforms - ну тут видно, что первый показ прилично тормозит, т.е. он на уровне стандартного win/wpf грида. - Но тут ничего уже и не сделаешь - инициализация скинов и загрузка необходимых .dll отнимает время. За то, повторный показ, показывает - что любой wpf/win из приведенных выше отстает весьма и весьма прилично.

по скорости скроллирования, самый медленный Xceed (и в tableview и в tableflow - несмотря на то, что они сделали самую большую высоту row - чтоб меньше данных показать :) ) - самый быстрый - стандартный.

тесты с DX продуктами делались в debug версии, перекомпиляция в release - даст где-то 20% по скорости...

но все равно, явно есть над чем работать. - Есть некоторое визуальное ощущение медленности показа - хотя, по цифрам от того же ксида, отставание в районе 30%. Разработчики обещали убрать это отставание :)


по методике замера - самое правильное место - это CompositionTarget.Rendering.
вот код тестовой формы:




в принципе, могу и тестовый проект выложить, если кому интересно.

Опять какие-то барабашки и алхимия без всякой конкретики. Выкладывай проект.
ЗЫ Гриды отдельно без форм не летают.

А где же образец для подражания - Winforms?