>> Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
Эта возможность позволяла вам стартануть приложение сразу, а не ждать его загрузки; однако, в системе с размером страницы в 4кб (win32) и производительностью диска в несколько МБ (старые винты 3-5 летней давности) это перестало давать преимущество. Можете на нем не фиксироваться. Тем не менее, она не теряется — jitter работает этапами и компилирует только «горячий» код, тот, который нужен.
>> я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его
Простота абстрактной машины CLR позволяет иметь скорость достаточно оптимизированной компиляции под x86 в 10-20 МБ/с (это подтвержденные цифры библиотеки libjit, родная от МС выдает и больше). 500 кб / 10 МБ/сек = 0,05 сек. Достаточно быстро, не находите?
>> байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
Здесь я вас расстрою. Байткод java и IL с легкостью превращается во вполне читаемые исходники. Так что программы в байт-коде гораздо легче реверсить, чем либы нативного с++. Вы проиграли :)
>> думаю МС просто лениво было бы
Это отличный аргумент в споре, продолжайте в том же духе :)
-+-
Вообще мы начали разговор про размер фреймворка, так что давайте завязывать спорить про производительность. В сети полно данных про сравнение компиляторов и программ — не абстрактных циклов и функций, а вполне законченных решений.
Мое мнение — на вкус и цвет фломастеры разные. Вы хотите иметь все и сразу. В жизни все доступно только через компромиссы.
P.S. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
При должном опыте — не сложнее, чем NAnt; конфиги и принцип в чем-то совпадают.
Кроме того, он используется как «режущая поверхность» у «комбайна» под названием Team Build из MS Team Foundation System.
В качестве домашнего средства я остановился на NАnt + CC.NET.
>> Но «выгоднее с точки зрения бизнеса разработчика» != «выгоднее для конечного пользователя», согласитесь?
Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
>> Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic
Вы путаете RAD и .net. Родоначальник RAD — это Delphi, там .net и не «пахло». Microsoft пропихивала VB в основном по той причине, что он тесно связан с COM, который интегрирован в Windows.
>>Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится
Именно это и несет с собой .net — компактные, удобные, быстрые, не требующие инсталляции программы. Беда не в платформе, а в быдлокодерах.
>> (и с нативными контролами)
В .net под windows нативные контролы (не все, правда), если что. Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
>> И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня?
Читайте выше: он внутри, и вам на него чихать. Он вам его по почте шлет и спамит, что ли? =) В .net перед выполнением сборка компилируется в машинный код (причем оптимизируясь с учетом архитектуры вашего конкретного процессора, а не абстрактного x86, который внутри уже давно RISC over CISC). Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке. Для наиболее частых запускаемых приложений специальный сервис windows хранит уже откомпилированные в машинный код сборки — так что даже на это время не тратится.
>> И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме?
Поверьте, нужны. Часто их используют не только для интроспекции кода.
>>а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Вернее сказать так — у меня много приложений, которые не тормозят, несмотря на то, что написаны с использованием .net fw. Так что это не к технологии придирки, а кривым рукам программистов.
>>Не вижу никакого смысла искать пруфлинк насчет того, что DirectX
предоставляет доступ к видеокарте. Не верите — не надо.
Речь шла (цитирую вас) «DirectX — нужен для прямого доступа к оборудованию, без него никак». Так вот, прямой доступ к оборудованию предоставляют абстракции HAL и драйвера. Сам DirectX — наоборот — изолирует вас от оборудования: для вас есть абстрактная графическая машина, и вы ею управляете. Все. Прямой доступ закончился со времен DirectX 5 (Когда он был еще DirectDraw).
>> или требует 30 мегабайтный инсталлятор
Вы внимательнее почитайте. Этот инсталлятор — для фреймворка, а не для программы. Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб. С возможностями, сравнимыми с MS Office. Речь об этом и о том как упростить и уменьшить далее сам инсталлятор фреймворка.
>> MSVCRT — входит в винду начиная с 98
Вы забыли указать версию библиотеки. В винде она обычно 7.1 (Win XP SP). Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе. Немного, но неприятно.
>> По поводу производительности Java/.NET… []… или не хочет использовать нативные контролы…
Простите, не вижу связи между нативными контролами и производительностью. Вы про Java? Так она не использует нативные контролы, потому что работает на разных платформах без перекомпиляции. На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
>> требует 30 мегабайтный инсталлятор…
Аналогично, отношения к производительности не имеет. Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
— Вывод мой, в общем-то прост. Вы чересчур импульсивно высказываете свое мнение, которое, к сожалению, опирается на факты, которые либо устарели, либо являются не фактами, а домыслами. Все попытки вам на это указать ни к чему не приводят. По поводу DirectX — вы неправы. По поводу MFC — уже сдались и признали неправоту.
Факт: в .net/java гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.
Я ясно выражаюсь? И есть ли смысл продолжать диалог?
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
Пруфлинк или вы — не разбираетесь
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
Пруфлинк или вы — не разбираетесь
DirectX — нужен для прямого доступа к оборудованию, без него никак
Пруфлинк или вы — не разбираетесь
Для MS SQL, например, это не так. Его оптимизатор позволяет сохранять планы даже для динамического SQL. План, грубо говоря — это распарсенное до атомарных операций выражение SQL, готовое к выполнению. После первого парсинга план помещается в кэш, после чего для его использования не нужно нагружать парсер, достаточно просто взять из кеша нужный запрос и подставить параметры.
Понятно, что параметризовать именем таблицы нельзя, зато можно держать планы для всех таблиц в БД (их редко бывает больше сотни-другой) для среднего проекта.
С другой стороны, наличие динамического sql, как правило, говорит о том, что что-то не так в датском королевстве вы используете БД не по назначению, заставляя ее выполнять задачи сервера приложений.
Не подводит: Microsoft.Office.Interop.Word.dll — это CCW (COM Callable Wrapper), автоматический сгенеренный тулзой TlbImp из состава Microsoft Windows SDK for .net. Все, что он делает — пробрасывает вызовы/объекты в COM-компоненты и худо-бедно рулит памятью (худо-бедно — потому что завязан на финализацию, и часто держит ссылки на COM-объекты дольше чем надо; часто — почти всегда:)
Автору — для создания путей лучше не использовать операции над строками, а использовать Path.Combine()
Хотя что в такой ситуации следует считать любимым делом? :)
>> попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас
И многое, и многое ещё :)
В точку, хоть и нечаянно :)
GUI ArcHitectures было бы лучше ;)) Шутка.
Спокойной ночи
Если хотя бы одно приложение станет чище и читабельнее после этого, это уже достаточное основание, чтобы переводить и публиковать.
Спасибо.
>> Почему бы не скомпилировать ее разработчику?
Читайте выше про оптимизацию
>> Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
Эта возможность позволяла вам стартануть приложение сразу, а не ждать его загрузки; однако, в системе с размером страницы в 4кб (win32) и производительностью диска в несколько МБ (старые винты 3-5 летней давности) это перестало давать преимущество. Можете на нем не фиксироваться. Тем не менее, она не теряется — jitter работает этапами и компилирует только «горячий» код, тот, который нужен.
>> я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его
Простота абстрактной машины CLR позволяет иметь скорость достаточно оптимизированной компиляции под x86 в 10-20 МБ/с (это подтвержденные цифры библиотеки libjit, родная от МС выдает и больше). 500 кб / 10 МБ/сек = 0,05 сек. Достаточно быстро, не находите?
>> байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
Здесь я вас расстрою. Байткод java и IL с легкостью превращается во вполне читаемые исходники. Так что программы в байт-коде гораздо легче реверсить, чем либы нативного с++. Вы проиграли :)
>> думаю МС просто лениво было бы
Это отличный аргумент в споре, продолжайте в том же духе :)
-+-
Вообще мы начали разговор про размер фреймворка, так что давайте завязывать спорить про производительность. В сети полно данных про сравнение компиляторов и программ — не абстрактных циклов и функций, а вполне законченных решений.
Мое мнение — на вкус и цвет фломастеры разные. Вы хотите иметь все и сразу. В жизни все доступно только через компромиссы.
P.S. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
Кроме того, он используется как «режущая поверхность» у «комбайна» под названием Team Build из MS Team Foundation System.
В качестве домашнего средства я остановился на NАnt + CC.NET.
Еще можно добавить (из более-менее известных):
— Apache Maven (Тынц)
— Boost Jam Tool (Тынц)
Из «диковинок»:
— Bake (Make для Boo) (Ты-тынц)
Это далеко не полный список
Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
>> Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic
Вы путаете RAD и .net. Родоначальник RAD — это Delphi, там .net и не «пахло». Microsoft пропихивала VB в основном по той причине, что он тесно связан с COM, который интегрирован в Windows.
>>Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится
Именно это и несет с собой .net — компактные, удобные, быстрые, не требующие инсталляции программы. Беда не в платформе, а в быдлокодерах.
>> (и с нативными контролами)
В .net под windows нативные контролы (не все, правда), если что. Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
>> И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня?
Читайте выше: он внутри, и вам на него чихать. Он вам его по почте шлет и спамит, что ли? =) В .net перед выполнением сборка компилируется в машинный код (причем оптимизируясь с учетом архитектуры вашего конкретного процессора, а не абстрактного x86, который внутри уже давно RISC over CISC). Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке. Для наиболее частых запускаемых приложений специальный сервис windows хранит уже откомпилированные в машинный код сборки — так что даже на это время не тратится.
>> И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме?
Поверьте, нужны. Часто их используют не только для интроспекции кода.
>>а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Вернее сказать так — у меня много приложений, которые не тормозят, несмотря на то, что написаны с использованием .net fw. Так что это не к технологии придирки, а кривым рукам программистов.
предоставляет доступ к видеокарте. Не верите — не надо.
Речь шла (цитирую вас) «DirectX — нужен для прямого доступа к оборудованию, без него никак». Так вот, прямой доступ к оборудованию предоставляют абстракции HAL и драйвера. Сам DirectX — наоборот — изолирует вас от оборудования: для вас есть абстрактная графическая машина, и вы ею управляете. Все. Прямой доступ закончился со времен DirectX 5 (Когда он был еще DirectDraw).
>> или требует 30 мегабайтный инсталлятор
Вы внимательнее почитайте. Этот инсталлятор — для фреймворка, а не для программы. Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб. С возможностями, сравнимыми с MS Office. Речь об этом и о том как упростить и уменьшить далее сам инсталлятор фреймворка.
>> MSVCRT — входит в винду начиная с 98
Вы забыли указать версию библиотеки. В винде она обычно 7.1 (Win XP SP). Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе. Немного, но неприятно.
>> По поводу производительности Java/.NET… []… или не хочет использовать нативные контролы…
Простите, не вижу связи между нативными контролами и производительностью. Вы про Java? Так она не использует нативные контролы, потому что работает на разных платформах без перекомпиляции. На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
>> требует 30 мегабайтный инсталлятор…
Аналогично, отношения к производительности не имеет. Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
— Вывод мой, в общем-то прост. Вы чересчур импульсивно высказываете свое мнение, которое, к сожалению, опирается на факты, которые либо устарели, либо являются не фактами, а домыслами. Все попытки вам на это указать ни к чему не приводят. По поводу DirectX — вы неправы. По поводу MFC — уже сдались и признали неправоту.
Факт: в .net/java гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.
Я ясно выражаюсь? И есть ли смысл продолжать диалог?
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
Пруфлинк или вы — не разбираетесь
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
Пруфлинк или вы — не разбираетесь
DirectX — нужен для прямого доступа к оборудованию, без него никак
Пруфлинк или вы — не разбираетесь
… далее вы поняли, куда грести.
Вы тролль-популист?
К каждому вашему замечанию выше хочется заметить следующее — «пруфлинк или вы фейл»
Понятно, что параметризовать именем таблицы нельзя, зато можно держать планы для всех таблиц в БД (их редко бывает больше сотни-другой) для среднего проекта.
С другой стороны, наличие динамического sql, как правило, говорит о том, что
что-то не так в датском королевствевы используете БД не по назначению, заставляя ее выполнять задачи сервера приложений.Автору — для создания путей лучше не использовать операции над строками, а использовать Path.Combine()