Здравствуйте, samius, Вы писали:
S>Если не сложно, приведи новые цифры. Мне просто интересно, а вопрос о выборе платформы для меня пока не стоит.
Если я правильно понял, под JIT компиляцией ты имел в виду то, что при первом запуске метода некоторое время уходит на компиляцию, если тот же код будет запущен второй раз, то повторной компиляции не будет.
Время для C# после второго запуска — 3-9сек, в среднем 4сек.-самый частый результат (600_000 записей). Я вполне доволен теперь.
Время для Delphi — очень удивился 8-10сек. (600_000 записей)
Код думаю вполне стал эквивалентным:
StringGrid1.RowCount := 600000;
DateTimePicker1.DateTime := Time();
for I := 0 to StringGrid1.RowCount - 1 do
for K := 0 to 6 do
StringGrid1.Cells[K,I] := IntToStr(I);
DateTimePicker2.DateTime := Time();
end;
dataGridView1.RowCount = 600000;
dateTimePicker1.Value = DateTime.Now;
for (int i = 1; i < 600000; i++)
{
for (int k = 0; k < 6; k++)
{
dataGridView1.Rows[i].Cells[k].Value = Convert.ToString(i);
}
}
dateTimePicker2.Value = DateTime.Now;
Здравствуйте, pers79, Вы писали:
P>Здравствуйте, samius, Вы писали:
S>>Если не сложно, приведи новые цифры. Мне просто интересно, а вопрос о выборе платформы для меня пока не стоит.
P>Если я правильно понял, под JIT компиляцией ты имел в виду то, что при первом запуске метода некоторое время уходит на компиляцию, если тот же код будет запущен второй раз, то повторной компиляции не будет.
Именно. Как правило, JIT компиляция занимает очень малое время (от времени выполнения программы). И это практически единственное, что отличает "ненормальный" exe от "нормального".
P>Время для C# после второго запуска — 3-9сек, в среднем 4сек.-самый частый результат (600_000 записей). Я вполне доволен теперь. P>Время для Delphi — очень удивился 8-10сек. (600_000 записей)
Во! Теперь хоть одного порядка цифры.
P> Код думаю вполне стал эквивалентным:
Функционально — да. Но если целью эксперимента было сравнить чисто шустрость гридов, то IntToStr(I) и Convert.ToString(i) (можно проще i.ToString()) можно было бы сделать не по 6 раз на строку, а один. Тогда цифры были бы более "чистые".
P>Вот такие пироги
К сведению: если действительно нужен большой грид, чтобы доканать пользователя, лучше использовать виртуальный грид. Время добавления в него информации не зависит от числа ячеек. Единственная проблема с большими гридами — затрудненная скроллинг навигация. Создать таблицу умножения от 0 до 1M вопрос долей секунды, а вот найти в ней результат умножения конкретных чисел стандартным скроллингом будет весьма утомительно.
В дотнете всеже есть узкие места. Например, чтение/запись БОЛЬШИХ файлов. Только там, где это действительно напрягает, можно использовать WinAPI.
Здравствуйте, pers79, Вы писали:
P>Время для C# после второго запуска — 3-9сек, в среднем 4сек.-самый частый результат (600_000 записей). Я вполне доволен теперь. P>Время для Delphi — очень удивился 8-10сек. (600_000 записей)
... P>Вот такие пироги
Гриды-то хоть скрытые, или ты еще и скорость инвалидации померял? И в Delphi отключи опцию String format checking. А вообще, конечно, гриды не показатель
Здравствуйте, samius, Вы писали:
S>К сведению: если действительно нужен большой грид, чтобы доканать пользователя, лучше использовать виртуальный грид. Время добавления в него информации не зависит от числа ячеек. Единственная проблема с большими гридами — затрудненная скроллинг навигация. Создать таблицу умножения от 0 до 1M вопрос долей секунды, а вот найти в ней результат умножения конкретных чисел стандартным скроллингом будет весьма утомительно.
Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы...
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, samius, Вы писали:
S>>К сведению: если действительно нужен большой грид, чтобы доканать пользователя, лучше использовать виртуальный грид. Время добавления в него информации не зависит от числа ячеек. Единственная проблема с большими гридами — затрудненная скроллинг навигация. Создать таблицу умножения от 0 до 1M вопрос долей секунды, а вот найти в ней результат умножения конкретных чисел стандартным скроллингом будет весьма утомительно.
C>Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы...
Раз уж это ответ на мой пост, полагаю что я в числе тех людей. Можно довести до меня выводы, которые я сделал по попугаям на синтетической задаче?
C>Г-да, это не профессионально.
Здравствуйте, samius, Вы писали:
S>>>К сведению: если действительно нужен большой грид, чтобы доканать пользователя, лучше использовать виртуальный грид. Время добавления в него информации не зависит от числа ячеек. Единственная проблема с большими гридами — затрудненная скроллинг навигация. Создать таблицу умножения от 0 до 1M вопрос долей секунды, а вот найти в ней результат умножения конкретных чисел стандартным скроллингом будет весьма утомительно.
C>>Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы... S>Раз уж это ответ на мой пост, полагаю что я в числе тех людей. Можно довести до меня выводы, которые я сделал по попугаям на синтетической задаче?
Так это Вам лучше знать. Вы же тратите свое время на составление и обсуждение абсолютно бессмысленных тестов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, pers79, Вы писали:
P>>Результаты такие: P>> на 30000: С# около 73сек. Delphi около 1сек P>>на 600000: С# не дождался окончания вывода на экран, Delphi — около 15сек. P>>проверял на виртуальной машине в VirtualBox. G>
G>Где бы еще найти пользователя, который сможет обработать хотябы 10000 записей в одном гриде.
Даже для этого идотского варианта есть в DataGridView так называемый virtual mode, о котором скорее всего автор теста и не подозревает.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Ну, оператор : ......... шарпу совсем не помешали бы. A>Если я правильно понял, что, он делает, лишь будет закапывать ошибки поглубже и усложнять отладку...
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Который ничем от C# 3 не отличается, окромя уродства под названием dynamic.
K>Неправда. Co- и contravariance тоже ценная ИМХО фича...
Здравствуйте, criosray, Вы писали:
C>>>Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы... S>>Раз уж это ответ на мой пост, полагаю что я в числе тех людей. Можно довести до меня выводы, которые я сделал по попугаям на синтетической задаче?
C>Так это Вам лучше знать. Вы же тратите свое время на составление и обсуждение абсолютно бессмысленных тестов.
Вы теперь тоже в этом замешаны Кроме того, Вы еще тратите свое время на совершение выводов за других. Сами себя не удивляете?
Вклиниваетесь в бессмысленное обсуждение постом, провоцирующим переход на личности. Видимо хотели блеснуть профессионализмом...
Здравствуйте, hattab, Вы писали:
H>Гриды-то хоть скрытые, или ты еще и скорость инвалидации померял? И в Delphi отключи опцию String format checking. А вообще, конечно, гриды не показатель
H>p.s. Да, машинка какая?
Я код привел, время смотрел через DateTimePicker. Я и не считаю гриды важным показателем — это всего лишь один из многих, и как уже народ отметил не самый важный. Гриды виды на экране, если я правильно понял твой вопрос, то не скрытые. В принципе меня в первую очередь и интересовала скорость обновления грида с точки зрения пользователя. А 600_000 записей взял, потому что на паре сотен без разницы чей грид и на чем программа написана — различий в скорости видно не будет.
Эти результаты на AMD x6000, 2G оперативка: P>>Время для C# после второго запуска — 3-9сек, в среднем 4сек.-самый частый результат (600_000 записей). Я вполне доволен теперь. P>>Время для Delphi — очень удивился 8-10сек. (600_000 записей)
А вот на виртуалке другие результаты (на ней всего 512M в качестве оперативки есть):
от NET результата не дождался,
Delphi видимо сам себе на уме — все те же 10сек. (такое ощущение, что ему в данном случае не важно какой процессор, какая память, да String format checking никак не повлиял)
Посмотрел еще на core2duo T7600 2.33ГГц 2G:
Delphi — все те же 10сек.
NET — тот же результат, что и на AMD 3-9сек, в среднем 4сек.-самый частый, я бы даже сказал стабильный, результат.
Видимо по скорости в данном случае NET выигрывает, а вот к памяти более требователен.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, pers79, Вы писали:
P>>>Результаты такие: P>>> на 30000: С# около 73сек. Delphi около 1сек P>>>на 600000: С# не дождался окончания вывода на экран, Delphi — около 15сек. P>>>проверял на виртуальной машине в VirtualBox. G>>
G>>Где бы еще найти пользователя, который сможет обработать хотябы 10000 записей в одном гриде.
___>Даже для этого идотского варианта есть в DataGridView так называемый virtual mode, о котором скорее всего автор теста и не подозревает.
Есстественно не подозреваю, т.к. написал уже, что толком ни на чем не работал. Лучше подскажи, что этот virtual mode дает — мне интересно.
G>>>Где бы еще найти пользователя, который сможет обработать хотябы 10000 записей в одном гриде.
___>>Даже для этого идотского варианта есть в DataGridView так называемый virtual mode, о котором скорее всего автор теста и не подозревает.
P>Есстественно не подозреваю, т.к. написал уже, что толком ни на чем не работал. Лучше подскажи, что этот virtual mode дает — мне интересно.
Здравствуйте, pers79, Вы писали:
P>Время для C# после второго запуска — 3-9сек, в среднем 4сек.-самый частый результат (600_000 записей). Я вполне доволен теперь. P>Время для Delphi — очень удивился 8-10сек. (600_000 записей) P> Код думаю вполне стал эквивалентным:
совсем не факт. Насколько я помню, дельфийский грид использует sparse array для хранения строк, там добавление достаточно долгое, зато хорошая оптимизация по памяти при хранении "разреженных" массивов
Здравствуйте, samius, Вы писали:
S>Здравствуйте, criosray, Вы писали:
C>>>>Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы... S>>>Раз уж это ответ на мой пост, полагаю что я в числе тех людей. Можно довести до меня выводы, которые я сделал по попугаям на синтетической задаче?
C>>Так это Вам лучше знать. Вы же тратите свое время на составление и обсуждение абсолютно бессмысленных тестов. S>Вы теперь тоже в этом замешаны Кроме того, Вы еще тратите свое время на совершение выводов за других. Сами себя не удивляете? S>Вклиниваетесь в бессмысленное обсуждение постом, провоцирующим переход на личности. Видимо хотели блеснуть профессионализмом...
Я думаю не стоит спорить из-за моего бессмысленного теста. Я не знаток — тут секрета нет. Решил вот такой тест провести, кто-то критикует, кто-то подсказывает. Кто переходит на личности на того все равно внимание не обращаю.
А по поводу количества сообщений в гриде не все однозначно:
взять промышленный объект, на котором идут испытания по какой-то подсистеме, все события происходящие за это промежуток кладутся в одну таблицу в базе данных (сразу говорю не я эту базу придумал, чтоб никто не говорил потом, что так базы данных делать нельзя). Прошло три часа, собралась комиссия и решила, давай те ка посмотрим, а какие события у нас в базу записались и соответствуют ли они тому, что было на испытаниях. Подойдут они к компьютеру и наберут интервал с 10.00 до 13.00, а им в ответ "событий слишком много — выберите интервал поменьше", они выбирают 10.00-12.00, а им снова "событий слишком много — выберите интервал поменьше", произойти это может, хотя бы потому, что за три часа в базу может попасть не только 100-300 событий, но и 3000.
Понятно что начнут распечатывать по частям, понятно что и решить эту проблему можно, понятно, что тест синтетический, но тем не менее хотелось бы чтоб проблемы такой не было вовсе, хотелось бы лучшего, хотелось бы наименьшего количества затрат труда с хорошим результатом. К этому я думаю все и стремятся.
Вопрос есть, по твоему опыту, как чаще приходится использовать DataGridView — в связанном или не связанном режиме?
Немного неясно по поводу этой строчки из MSDN:
Виртуальный режим должен использоваться, чтобы поддерживать значения несвязанных столбцов, когда элемент управления DataGridView находится в режиме привязки данных. Сортировка по несвязанным столбцам в режиме привязки данных не поддерживается.
Я так понимаю, это используется (т.е. основное назначение данного режима). когда например привязал я DataGridView к источнику данных и дополнительно добавил в грид свои столбцы, не связанные с источником данных, которые мне тоже нужно обрабатывать.
Здравствуйте, pers79, Вы писали:
P>Видимо по скорости в данном случае NET выигрывает, а вот к памяти более требователен.
Я вижу ты не понял главного из моего поста: при обновлении ячейки происходит инвалидация оной, и эта инвалидация может быть сильно по разному реализована. Как реализовано в Delphi я знаю, и там это сильно не оптимально т.к. инвалидация происходит всякий раз при обновлении, а метод позволяющий включить режим обновления забыли вынести в паблик... Но мы же в нативе, посему можно применить маленький хак: PBoolean(Cardinal(StringGrid1) + 816)^ := True; (перед добавлением) и PBoolean(Cardinal(StringGrid1) + 816)^ := False; StringGrid1.Invalidate; (после обновления). У меня (PM 1.7, 512) время 3 сек. Стабильно. Но еще раз говорю: я это пишу не с целью померяться органами, ибо не считаю любую синтетику оправданной.
Здравствуйте, pers79, Вы писали:
P>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, criosray, Вы писали:
C>>>>>Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы... S>>>>Раз уж это ответ на мой пост, полагаю что я в числе тех людей. Можно довести до меня выводы, которые я сделал по попугаям на синтетической задаче?
C>>>Так это Вам лучше знать. Вы же тратите свое время на составление и обсуждение абсолютно бессмысленных тестов. S>>Вы теперь тоже в этом замешаны Кроме того, Вы еще тратите свое время на совершение выводов за других. Сами себя не удивляете? S>>Вклиниваетесь в бессмысленное обсуждение постом, провоцирующим переход на личности. Видимо хотели блеснуть профессионализмом...
P>Я думаю не стоит спорить из-за моего бессмысленного теста. Я не знаток — тут секрета нет. Решил вот такой тест провести, кто-то критикует, кто-то подсказывает. Кто переходит на личности на того все равно внимание не обращаю.
P>А по поводу количества сообщений в гриде не все однозначно:
P>взять промышленный объект, на котором идут испытания по какой-то подсистеме, все события происходящие за это промежуток кладутся в одну таблицу в базе данных (сразу говорю не я эту базу придумал, чтоб никто не говорил потом, что так базы данных делать нельзя). Прошло три часа, собралась комиссия и решила, давай те ка посмотрим, а какие события у нас в базу записались и соответствуют ли они тому, что было на испытаниях. Подойдут они к компьютеру и наберут интервал с 10.00 до 13.00, а им в ответ "событий слишком много — выберите интервал поменьше", они выбирают 10.00-12.00, а им снова "событий слишком много — выберите интервал поменьше", произойти это может, хотя бы потому, что за три часа в базу может попасть не только 100-300 событий, но и 3000.
А зачем все 3000 сразу в грид пихать? Можно делать подгрузку по частям (через тот же virtual mode) с кешированием или какой-нить ненавязчивый пейджинг (в случае web).
Не нужны пользователю сразу все 3000 записей в гриде.
Здравствуйте, pers79, Вы писали:
P>Здравствуйте, samius, Вы писали:
P>А по поводу количества сообщений в гриде не все однозначно:
P>взять промышленный объект, на котором идут испытания по какой-то подсистеме, все события происходящие за это промежуток кладутся в одну таблицу в базе данных (сразу говорю не я эту базу придумал, чтоб никто не говорил потом, что так базы данных делать нельзя). Прошло три часа, собралась комиссия и решила, давай те ка посмотрим, а какие события у нас в базу записались и соответствуют ли они тому, что было на испытаниях. Подойдут они к компьютеру и наберут интервал с 10.00 до 13.00, а им в ответ "событий слишком много — выберите интервал поменьше", они выбирают 10.00-12.00, а им снова "событий слишком много — выберите интервал поменьше", произойти это может, хотя бы потому, что за три часа в базу может попасть не только 100-300 событий, но и 3000.
Тут нужна голова а не грид. У комиссии нет задачи "просмотреть все записи с 10:00-12:00". Просмотром грида они решают свою более высокую задачу (найти аномалии, оценить тенденции и пр.) только потому что программист не предоставил им удобный сервис для решения прямой задачи.
P>Понятно что начнут распечатывать по частям, понятно что и решить эту проблему можно, понятно, что тест синтетический, но тем не менее хотелось бы чтоб проблемы такой не было вовсе, хотелось бы лучшего, хотелось бы наименьшего количества затрат труда с хорошим результатом. К этому я думаю все и стремятся.
Нужно стремиться удовлетворить заказчика, занимаясь прежде всего решением его задач.
Здравствуйте, samius, Вы писали:
C>>>>Всегда удивляли люди, которые меряют попугаев на синтетической задаче, и делают на основе этого какие-то там выводы... S>>>Раз уж это ответ на мой пост, полагаю что я в числе тех людей. Можно довести до меня выводы, которые я сделал по попугаям на синтетической задаче?
C>>Так это Вам лучше знать. Вы же тратите свое время на составление и обсуждение абсолютно бессмысленных тестов. S>Вы теперь тоже в этом замешаны
Нет, не замешан. S>Кроме того, Вы еще тратите свое время на совершение выводов за других. Сами себя не удивляете?
Я на знаю что Вы подразумеваете под "совершение выводов за других"... Я лишь прокомментировал весь этот бессмысленный топик с намеком на то, что Вам лучше бросить эту пустую затею.
8-10сек. (600_000 записей)
И в Delphi отключи опцию String format checking. А вообще, конечно, гриды не показатель 
