М>>>сильно. а какое отношение это имеет к JIT и прочим умным словам? Ф>>это имеет отношение к .Net. М>создание 400х чекбоксов в гриде? помилуйте. давайте использовать инструменты по назначению. какие проблемы реализовать _один_ элемент управления самостоятельно? совсем уже обленились. тут же тривиально все. будет летать на любой платформе. давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Не понимаю. Почему вот этот тупейший код:
var table = $(document.body).append('<table>');
for(var i=0; i < 20; i++){
var tr = $('<tr>');
for(var j=0; j < 20; j++){
var td = $('<td>');
var chk = $('<input type="checkbox">');
chk.bind('click', function(){$(this).parent().css('background-color', $(this).is(':checked') ? 'red' : 'white')});
td.append(chk);
tr.append(td);
}
table.append(tr);
}
Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить.
Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30?
Здравствуйте, мыщъх, Вы писали:
м>давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Не-не, расскажи, сколько ресурсов требует чекбокс в WPF. Если вспомнить, что в дотнетах память не ресурс, получится что ресурсов ему не требуется
м> вы бы еще создали 400 потоков и сказали, что система -- фуфло
У меня прямо сейчас в системе 903 потока, в серверном процессе пул периодически разрастается до полутора тысяч, иничо
M>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих?
мы говорим за WPF или дотнет? за WPF не знаю, в код дотнета смотрел дизасмом. ничего ужасного в нем не нашел. нормальный такой код. взаимодействие с нативным кодом, конечно, через задницу, но в рамках управляемого кода особых тормозов быть не должно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>а вы код правильного кросс-платформенного приложения видели? это же ужос просто.
Ну вот я сейчас смотрю на такой код (наш) и ничего страшного там не вижу.
М>совместимость компиляторов сильно хромает и хз какое подмножество стандарта на каком компиляторе реализовано.
Это вы про код использующий спец. фичи конкретного компилятора или про что? Даже Буст (уж на что полная извращений библиотека) без проблем компилируется везде. А у вас какие-то более хитрые коды? )))
М>а кросс-платформенных библиотек кот накакал.
ЭЭэ, это в сравнение с чем? Все библиотеки что мы используем кроссплатформенные...
Здравствуйте, gandjustas, Вы писали:
G>Ничего, даже если запустится, то работать будет невозможно.
Почему невозможно? А если это какой-нибудь конвертер файлов просто?
Кстати, я вообще то сам Java не люблю, но совсем по другим причинам. А тут не могу согласиться с такими наездами на неё — кроссплатоформенность там всё же реальная.
G>Какие платформы входят в это множество?
Потенциально (наши инструменты это поддерживают) можно под: windows, osx, все unix'ы, OpenVMS, OS/2, iOS, WinCE, PalmOS и т.п. На практике для бизнеса полезны только: Windows (с большим приоритетом), OS X, Linux.
G>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО.
Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, мыщъх, Вы писали:
М>>а вы код правильного кросс-платформенного приложения видели? это же ужос просто. _>Ну вот я сейчас смотрю на такой код (наш) и ничего страшного там не вижу.
мой код тоже компилируется везде. но мне везет. у меня даже стандартного в/в нету. у меня даже malloc'а нету. есть входной буфер. есть преаллоцированный буфер. но если посмотреть в код FireFox, то становится дурно.
М>>совместимость компиляторов сильно хромает и хз какое подмножество стандарта на каком компиляторе реализовано. _>Это вы про код использующий спец. фичи конкретного компилятора или про что?
берем FireFox. пытаемся компилировать ранние версии. у меня получилось собрать только 2.0, а более ранние — MS VC 6 выдает внутреннюю ошибку компиляции и падает, а MS VC 2008 выдает кучу ошибок и ничего не собирает.
последние версии лиса в этом смысле сильно продвинулись вперед, но проблем все равно куча. и для сборки приходится деражть определенную среду. вот тут наконец дали мне полную версию студии (не экспресс), на ней уже не собирается.
> Даже Буст (уж на что полная извращений библиотека) без проблем > компилируется везде. А у вас какие-то более хитрые коды? )))
лис, хром -- у всех них довольно жесткие требования к компиляторам. сборка новых версий это как бы не проблема (раз смогли собрать они -- смогу и я). а вот если хочешь собрать какую-то древность -- то нужной версии компилятора не найти, особенно если это не gcc, а коммерческий компилятор.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Так при установке же можно прогонять. Ставишь новый пакет -- система его прожёвывает на фоне и выкатывает на диск уже супер-оптимизированные бинарники.
Меня выбешивает даже то, как на i5 ngen жуёт сопли при установке какого нить .NET FW, а тут для всех прог так? Да ну нафиг!
Здравствуйте, Mamut, Вы писали:
M>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30?
Потому что WPF плохо работает в таких сценариях. Никто же не говорит, что это панацея на все случаи жизни. Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты). Если нужны, то придется учиться пользоваться технологией, что включает и умение выкручиваться в тормозных ситуациях. Вот у нас на проекте первоначальный вариант рисования сложного графика тратил на рендеринг около 10 секунд. Сейчас уходит меньше секунды притом, что количество данных только возросло. Потому что научились. Потому что нужны были другие фичи WPF, такие, например, как подстройка DPI.
У нас есть и другой проект, вебовский, с тем же Ext-ом. Там сначала тоже всё было быстро в GUI, но начали наворачивать и пошли тормоза. И веб-разработчики тоже стали искать пути оптимизаций.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ничего, даже если запустится, то работать будет невозможно.
_>Почему невозможно? А если это какой-нибудь конвертер файлов просто?
На мобилке? Где по-умолчанию и доступа к ФС нету?
_>Кстати, я вообще то сам Java не люблю, но совсем по другим причинам. А тут не могу согласиться с такими наездами на неё — кроссплатоформенность там всё же реальная.
Ни разу. j2ME сильно отличается j2EE как ни крути. Как в библиотеках, так и в подходе к разработке.
G>>Какие платформы входят в это множество?
_>Потенциально (наши инструменты это поддерживают) можно под: windows, osx, все unix'ы, OpenVMS, OS/2, iOS, WinCE, PalmOS и т.п. На практике для бизнеса полезны только: Windows (с большим приоритетом), OS X, Linux.
Ага, то есть ни одной мобилки, а сейчас всякие планшеты набирают оборот.
G>>Кроссплатформенность нужна исчезающе малому проценту вендоров ПО. _>Типа гораздо выгоднее разработать отдельное приложение под каждую платформу, да?
Ну вот производители фотошопа считают так. У них разные билды под разные оси.
М>>>сильно. а какое отношение это имеет к JIT и прочим умным словам? Ф>>это имеет отношение к .Net. М>создание 400х чекбоксов в гриде? помилуйте. давайте использовать инструменты по назначению. какие проблемы реализовать _один_ элемент управления самостоятельно? совсем уже обленились. тут же тривиально все. будет летать на любой платформе. давайте я вам не буду объяснять сколько ресурсов кушает один элемент управления?
Там получается каждый чекбокс в одно окно GUI? Тогда действительно маразм, но даже не WPF или дотнета, а виндового GUI — что нет отдельного понятия widget, хотя надо было сделать ещё лет 10 назад.
Ф>> именно библиотеки хорошо характеризуют платформу, на которой они написаны М>создание 400х чек-боксов показывает, что программисты совсем разучились думать и хотят готовых _стандартных_ компонентов под нестандартную задачу, хотя она на чем угодно реализуется элементарно и без тормозов и без ограничения на кол-во элементов в гриде. хоть миллион на миллион. ловим событие "щелчок", смотрим где мыша, вычисляем позицию верхнего левого угла элемента, из битового массива берем его состояние, меняем на противоположное и рисуем либо галку либо пустое место.
А так ещё лучше — хотя надо откуда-то изображения галочек взять. Это ж целого дизайнера привлекать.
Здравствуйте, stasgoo, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>При установке прогонять аналог ngen'а, и все пучком, по идее
S>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, stasgoo, Вы писали:
S>>Интеловское небязательно. Но если будем компилить с максимальной оптимизацией надо чтобы все расширения типа SSE3 присутствовали. Т>На AMD я сталкивался с забавным: по флагам проца поддержка SSE3 есть, а по факту падает с illegal instruction.
Какая модель процессора? Какая ОС?
(вообще-то очень слабо верится, слишком очевидный ляп.)
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, stasgoo, Вы писали:
S>>Здравствуйте, Mamut, Вы писали:
M>>>При установке прогонять аналог ngen'а, и все пучком, по идее
S>>Не получится пучков У JIT-а есть фатальный недостаток: безблагодатность жёсткие ограничения на время работы. Как бы не хотелось, но от многих оптимизаций придётся отказаться, чтобы пользователь не фалломорфировал, полдня ожидая JIT при запуске офиса.
N>Зато их вполне можно делать инкрементально. Выделить один тред и пол-ядра (или сколько сказано в настройках) на работу statclock profiler (такой, что меряет место работы по таймерным сигналам) и напускать JIT на занятые места, контролируя, чтобы он не превысил разрешённую долю процессорного ресурса системы. Технологически это тривиально.
.net 4.5 так и делает, собирает статистику, а потом в бекграунде ngen-ит, то что часто используется
M>>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30? MM>Потому что WPF плохо работает в таких сценариях. Никто же не говорит, что это панацея на все случаи жизни. Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты).
Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится?
Здравствуйте, IT, Вы писали:
IT>>>У вас трейдеры прямо с собственных телефонов торгуют? Впервые слышу. Что касается браузеров, то тут java точно не нужна. Это ошибка, переходите срочно на ASP.NET MVC. G>>Вообще-то трейдинговых приложений под iPhone/iPad вагон и маленькая тележка.
IT>Например, amazon.com.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaPerouse, Вы писали:
LP>>Признай наконец, что ляпнул чушь. IT>Давай так. Ты выключишь свою демагогию, а я свою включать не буду. Договорились? Вот и славненько.
Стандарты демагогии в этой ветке устанавливаешь именно ты.
LP>>Если логика вынесена на клиент, существует возможность замены это логики путем изменения клиента. Если логика на сервере, то на нее можно влиять только подбором входных данных; верификация эти данных на стороне сервера способно устранить большинство проблем. IT>Я не знаю в каком окружении вы работаете и какой у вас уровень доверия к пользователям, но у нас описываемые тобой проблемы отсутствуют как класс.
У нас заказчики незапароленный дамп бд в пубичные фалообменники заливают, поэтому затраты на безопасность финансово неоправданны. Но ты-то пишешь для банков, поэтому уровень безопасности должен быть не просто другой, а качественно другой.
IT>>>Так ты про энергенику. А мы тут всё больше про банки. LP>>Не знаю про что вы говорите, я говорю о .net и java.
IT>Юлишь. То ты про то, что должно быть известно разработчику банковских систем. Потом вдруг сразу "Какие еще трейдеры?". А теперь оказывается ты не знаешь про что вы говорите
Я тебе назвал конкретный факт, который должен быть известен разработчику банковских систем, но сам факт имеет отношение не только к финансовой среде. Демагогию разводишь.
LP>>На RSDN была новость о том, что команду разработчиков разогнали, оставив лишь двоих для выпуска последней версии. Вот я и спрашиваю, кто же прав, о каком переходе на личности ты говоришь? IT>Мало ли кто где кого разогнал и по каким причинам? Ты прямо такой доверчивый, что веришь любой новости на RSDN.
Нет бы дать ссылку, хоть как-то подтверждающую свои слова. Я сослался на новость, а ты на что?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Mamut, Вы писали:
M>>>Который jQuery, тупое создание 400 чекбоксов с максимально тупым назначением событий каждому чекбоксу... И не тормозит. Более того, создание аналогичного в каком-нить ExtJS тоже не будет тормозить. M>>>Но нет, в WPF это низзя ни в коем случае, вы шо. Нужно в обязательном порядке делать собственный контрол на каждый чих? Где эти чихи начинаются? На 20 чекбоксах? На 30? MM>>Потому что WPF плохо работает в таких сценариях. Никто же не говорит, что это панацея на все случаи жизни. Надо понимать, нужны ли тебе бенефиты WPF (шаблоны, масштабируемость, биндинги, эффекты). M>Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится?
Не понял. А причем здесь влияние "выделенной хрени"? Биндинги к рендерингу вообще никак не относятся... Ладно, давай по другому напишу. Когда ты создаешь чекбоксы средствами HTML, то по сути ты говоришь браузеру отрендерить чекбоксы. Причем набор вариантов ограничен допустимыми значениями тега type и слабыми возможностями влияния на внешний вид чекбокса. В результате браузеру не нужно особо напрягаться. Он видит всю картину — столько-то чекбоксов на такой-то площади экрана. Он заранее знает, как это оптимизировать, ведь внешний вид вполне себе фиксирован... Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
M>>Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится? MM>Не понял. А причем здесь влияние "выделенной хрени"? Биндинги к рендерингу вообще никак не относятся... Ладно, давай по другому напишу. Когда ты создаешь чекбоксы средствами HTML, то по сути ты говоришь браузеру отрендерить чекбоксы. Причем набор вариантов ограничен допустимыми значениями тега type и слабыми возможностями влияния на внешний вид чекбокса. В результате браузеру не нужно особо напрягаться. Он видит всю картину — столько-то чекбоксов на такой-то площади экрана. Он заранее знает, как это оптимизировать, ведь внешний вид вполне себе фиксирован... Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
Это все — демагогия, пытающаяся прикрыть отмазки, пытающиеся прикрыть кривизну реализации. Ничего из описанного даже близко не объясняет, почему грид с 20x20 чекбоксами тормозит.
Здравствуйте, MxMsk, Вы писали: M>>Стопстопстоп. Отрисовка грида с 20x20 чекбоксов — это настолько сложня задача, что вся выделенная хрень не может с этим справится? MM>Не понял. А причем здесь влияние "выделенной хрени"? Биндинги к рендерингу вообще никак не относятся... Ладно, давай по другому напишу. Когда ты создаешь чекбоксы средствами HTML, то по сути ты говоришь браузеру отрендерить чекбоксы. Причем набор вариантов ограничен допустимыми значениями тега type и слабыми возможностями влияния на внешний вид чекбокса. В результате браузеру не нужно особо напрягаться. Он видит всю картину — столько-то чекбоксов на такой-то площади экрана. Он заранее знает, как это оптимизировать, ведь внешний вид вполне себе фиксирован... Теперь берем WPF. Каждый чекбокс оказывается отдельным контролом. Контрол поддерживает шаблоны, предугадать его внешний вид нереально. Я могу туда хоть таб-контрол запихнуть! Целостной картины тоже нет. Всё это впихнуто в грид, который тоже контрол со своими заморочками. Свободы для оптимизации значительно меньше. Зато фич по кастомизации больше. За них и платим.
HTML тут практически такие же возможности предоставляет что и WPF в плане кастомизации внешнего вида чекбокса.
