.NET Framework Client Profile

    Введение

    Как известно размер .NET фреймворка увеличивается от релиза к релизу. Но, к сожалению, не у всех потенциальных пользователей широкий безлимитный канал.
    Стояла задача — определить какой .NET Framework, поддерживающий WPF, оптимален с точки зрения простоты распространения. Ведь не хочется терять пользователей из-за лишних мегабайт в установщике.
    Т.е. надо было принять решение какой .NET Framework использовать: .NET 3.0 или .NET 3.5.


    Сравнение

    Главный плюс .NET 3.0 — он предустановлен в операционной системе Vista
    Плюсы .NET 3.5
    • функционально более богат по сравнению с предшественником
    • имеет Client Profile версию (подробности ниже)

    В результате был выбран .NET Framework Client Profile. Т.к. в этом случае пользователи XP должны будут скачать приблизительно 30 мегабайт (фреймворк + приложение), а пользователи виста около 12ти. Следует заметить, что некоторые пользователи Windows Vista получат .NET 3.5 через Windows Update и для них установка обойдется скачиванием только самого приложения.

    После принятия решения появилось желание узнать мнение хабра-сообщества по этому вопросу. Но публикаций, где бы затрагивался .NET Framework Client Profile, я не нашел. Поэтому решил осветить этот воброс.

    Описание .NET Framework Client Profile

    .NET Framework Client Profile, это 28 MB сборок, чаще всего используемых при создании десктоп приложений на .NET.
    В него вошли:
    • Common Language Runtime (CLR)
    • ClickOnce
    • Windows Forms
    • Windows Presentation Foundation
    • Windows Communication Foundation

    Детальное описание — Introducing the .NET Framework Client Profile
    Подробный список сборок — .NET Framework Client Profile Assemblies

    Размер закачки полного фреймворка (3.5SP1)

    Нет установоленных фреймворков ~56 MB
    Установлен 2.0 ~50 MB
    Установлен 2.0SP1 ~33 MB
    Установлен 3.0SP1 ~10 MB

    Более подробно — On the Size of the .NET Framework

    P.S. Было бы интересно услышать ваши мнения по этому поводу.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 24

      +2
      Щас тут набегут тролли с их модемным каналом и будут орать .net отстой даешь asm

      Если по существу, ключевой вопрос для меня когда выбирал framework это кто ваш пользователь. Если это буржуй (Европа или штаты) у них там безлимитка стоит просто смешные деньги и тарифицированных пакетов почти нет — поэтому тут однозначно что вам удобнее и с чем у вас будут быстрее выпускаться версии.

      Если это наш родной советский пользователь — то тут конечно проблема, ибо 50 метров это большая проблема (для жителей вне столиц)
        0
        Спасибо, программа будет на двух языках (по крайней мере пока) английский и русский. Поэтому хочется всех осчастливить:)
        –7
        Возьмем Тотал-Коммандер-подобную программу. Я лучше скачаю быстрый, мало-памяти-требующий и весящий пару мегабайт Total Commander, чем его воображаемый аналог весом в 58 Мб, который еще и тормозить будет. Зачем, спрашивается?

        Ставьте свой .NET себе на многогигабайтный 8-ядерный сервер, если уж жить без него не можете, а пользователям сырые, кривые и неэффективнфые технологии не предлагайте. Что в нем такого, что оправдывает такую трату ресурсов?

        p.s. Я хоть и провинциал (а не тролль с модемным каналом), но на скорость не жалуюсь — до нескольких мегабит в секунду, но памяти, диска и процессора мне на всякую .NET-ную фигню жалко. научитесь сначала писаьт эффективные программы.

        К тому же неэффективному сборщиуку мусора, неэффективной CLR и JIT-у на моем компьютере делать нечего.

        p.p.s. Вы бы еще тут на php + GTK предлагали писать — такая же фигня (хотя нет, .NET весит больше).

        p.p.p.s Бесят дистрибутивы размером десятки и сотни мегабайт. такое ощущение, что платят зарплату программистам помегабайтно.
        • UFO just landed and posted this here
            –2
            > Ты ограничен, у тебя нету фантазии.

            Это к чему?)) Или .NET только для фантазеров? Далеких от рещения реальных задач?

            > Кстати за счет GC код типа for (;;) new obj; delete obj; будет выполняться быстрей чем на твоем asm или ещё на чем ты там помешан.

            И памяти потратит столько же? И где интересно нужен пустой цикл, создающий и удаляющий объекты? И зачем delete при использовании GC?

            У GC есть вполне конкретные недостатки  — подвисания в работе программы, большой расход памяти, кроме того с увеличением адресного пространства и количества объектов он становится не шибко эффективным.

            В любом случае, .NET тормозной не только из-за GC.

            >> Что в нем такого, что оправдывает такую трату ресурсов?
            > Ты идиот.

            Слив защитан?
            • UFO just landed and posted this here
                –1
                Наверно ты уже сам догадался что твое «подтверждение» для меня ровным счетом ничего не значит. Иди лучше учи уроки, тролль.
                • UFO just landed and posted this here
                    0
                    Ого)) Стоило уперекнуть тролля в школинге — посыпались нормальные факты.

                    Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других». Более того, кроме Qt/GTK вы забыли упомянуть еще и XUL  — тоже дурацкую и тормозную библиотеку (или платформу?).

                    MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.

                    DirectX — нужен для прямого доступа к оборудованию, без него никак.

                    Остальное  — уродливые монстроподобные библиотеки/рантаймы, создатели которых плевали на всякую оптимизацию (и на использование нативных контролов, вот это им точно простить нельзя!), и которые пытаются из C++ имитировать какой-то более высокоуровневый язык. Цели, преследуемые ими были другие. Кратко они называются RAD.

                    Во-первых, стоит заметить что программирование на C/C++ — сомнительное удовольствие в силу абсолютной невменяемости синтаксиса да и многих неудобств языка, нехватки автоматического управдения памятью, и т.д. Отладка программ на них довольно сложна, а ошибку допустить легко. Ручная работа с указателями, например, очень даже этому способствует.так же неопытный программист легко может оставить какое-нибудь переполнение буфера к примеру. Понятно, что для нормального программирования на них нужен большой опыт и знания. Это никак не может устроить современную индустрию разработки ПО. Да и думаю, самими программистам вряд ли нравится, вот они и убегают на Питон, Руби и прочие пакости.
                    Первая цель java/.NET — снижение требуемой квалификации для написания кода. Если язык устроен так, что не позволяет переполнить буфер, или создать утечку памяти без специальных намерений — значит зха программирование можно посадить индксов или студентов. Это очень хорошо. так как денег они просят намного меньше чем опытный программист.

                    Ну и второй фактор. Скорость разработки на яве и дотнете тоже (вроде как) выше. Опять же это не может не радовать разработчиков, ибо позволяет как можно быстрее выпустить (пусть сырой, пусть неэффективный) прототип/продукт и оставить конкурентов позади. Именно этому учат нас современные книги о разработке. Правда, там потом рекомендуется делать оптимизацию, рефакторинг, но если продукт уже продается — стоит ли с этим заморачиваться, тратить на это деньги? Наверно нет. тем более что рефакторинг «индусского» кода  — сомнительное удовольствие.

                    Ну и третий фактор (зачем, зачем же нужен байт-код?) — возможность использовать при разработке 3rd-party closed-source компоненты. ведь на Си/Си++ тому, кто хочет продавать свой компонент, придется делать обфускауцию, или как то по другому защищать свои права (чтоб никто не узнал что их код писали студенты, ага), а в случае с java/.NET можно продавать/покупать компоненты, не получая исходников. Считается (видимо), что это развивает индустрию. Считается, что это одна из причин успеха java.

                    Ну и в случае с .NET думаю есть еще хитрый план очередного подсаживания программистов (и всех конечных пользователей) на Windows (+MSSQL +IIS +что они там еще накодили).

                    Нужен ли конечному пользователю ПО байт-код? Нафиг не нужен. ибо ему плевать кто там от кого прячет свой код. Нужен ли JIT? Нет байт-кода — нет компилятора. Нужно ли конечному пользователя 58 Мб библиотек на все случаи жизни? Тоже не нужно. Напишите уже пакетный менеджер и ставьте/распространяте с прграммой только непосредственно используемые библиотеки.

                    Нужно ли переходить с C++ на более удобный язык? Нужно ли упрощать отладку и разработку? Конечно нужно, я тоже за то чтобы отобрать возможность ручной работы с указателяим без особой надобности. Но нужно ли «более удобный» язык делать намного менее производительным, из-за всяких байт-кодов и многоэтажных фреймворков? Не уверен.

                    Кстати, фреймворк существует (вроде как) в 4 версиях: 1.0, 1.1, 2.0, 3.* — и новая версия *не замещает* старую (сам видел компьютеры с несколькими версиями фреймворка)! Значит количество хлама на диске пользователя будет только расти.

                    Еще один фактор, снижающий производительность  — многоэтажные объекты, построенные друг на друге, фреймворк, содержащий кучу кода на все случаи жизни.

                    Ну и стремление к мультитредингу приводит к появлению тормозного кода, со всякими блокировками (в результате чего 2-поточная программа может работать на 2 ядрах медленнее однопоточной).

                    Есть ли среди целей создания java/.NET цель получения хорошимх/быстрых программ? Нет, нет и нет. Быстрой должна быть разработка, а то что программа получилась тормозной — не страшно, сейчас же у всех 4ядерные процессоры и 4 Гб памяти, разве нет?

                    Имхо, Этот подход приемлем к серверному ПО — ну написал индусский код, ну плати уж тогда за более мощный сервер, или купи 2 сервера там. Но почему платить должен конечный пользователь?  — ума не приложу.

                    Я готов поверить, что в простых циклах выделения/удаления объектов Java/GC обгоняет ручное управление памятью (за счет более качественной оптимизации кода в первую очередь, ну и за счет того что там объекты тупо не удалются). Но посмотрите на реальный Java/.NET приложения.Я не видел ни одного, которое бы запускалось мгновенно (это при том что считается якобы java-компилатор+GC более эффективен чем C++). Отъесть по 100-200 Мб памяти у них считается нормльно. Видимо в представлении разработчиков пользователь работает исключительно с одной программой одновременно, и закрывает ее прежде чем запустимть другую. И еще этому гипотетическому пользователю доставляет удовольствие смортеть на сплеши.

                    Эффективный код, кроме отдельных пользователей, сегодня никому не нужен (да и никогда не был нужен видимо).

                    Win-Разработчики идут сейчас «путем Линукса» — цеплять даже к простому GUI-приложению по 100 Мб библиотек.

                    > Некоторые же недостатки по производительности из за сборщика мусора можно устранить если подойти к конкретной задаче с умом, так например подвисание при сборке можно убрать используя так называемый pooling, расход — вызовом сборщика в ручную в нужных местах.

                    Приложение — браузер. Когда можно вызывать сборщик так, чтобы не помешать пользователю? Объясните ка это товарищам-инвалидам из Оперы.

                    > Но учитывая развитие аппаратной составляющей, и развитие технологий в целом, большая часть прикладных и системных программ (если пишет не школьник) не требует этих специальных методов оптимизации при работе на среднем современном компьютере.

                    Какой компьютер вы считаете средним? На селероне с 512 Мб памяти тормоза есть. Увеличивать память (а память дешева как никогда this days) лениво, и кроме того есть подозрение что засыпание будет намного медленее с большим объемом.

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

                    Пишите уж сразу прямо — .NET не для провинциалов-замкадышей-нищебродов. Хотя работа у меня есть (и слава богу она не требует использования ни java ни .NET приложений!) и я могу позволить себе регулярно апгредить железо — но зачем? лазать по форумам, отслеживать кто там какую видеокарту выпустил, путаться в аббревиатурах и каждые полгода обновлять все железо мне абсолютно неинтересно.

                    У дешевого железа еще одно преимущество  — если что-то сломается, его просто можно выкинуть и не мучаться с гарантиями и прочей мутью.

                    > А там более если пишешь для удовольствие — можно взять любой язык или платформу которая вам нравиться. Главное только не нести чушь о том чего не знаете.

                    Только не надо называть эти технологии передовыми, и расписывать во всю, и так далее. хелловорлд на любом нормальном языке должен быть хелловорлдом, а не тянуть за собой тонну библиотек и запускаться по полминуты.

                    > Сам .NET версии 3.5 включает в себя огромнейшее количество готовых р�! �шений с хорошей документацией и выполненных в одном едином стиле,
                    придерживаясь концепций ООП. Такой функционал и возможности тотал командеру вашему и не снились, и это 50 мегабайт,

                    Зато «мой» тотал коммандер умеет хорошо работать с файлами, и не тормозит — вашему .NET такое и не снилось тем более. А используется ли там ООП (хотя он по моему во всех программах за последние лет 20 точно есть), и какой там стиль кода — мне по барабану.

                    > И сравнение объёма с объёмом готовой программы чёткой направленности является форменной спекуляцией и лицемерием.

                    Да просто халявщики из МС не могут нормально ничего сделать. Ну слинкуйте вы нужные библиотеки статически (если конечно ваш .NET это позволяет), если у вас небольшая программа — в чем проблема то?

                    > который в ближайшее время будут поставляться вместе с OS Win7 которую вы готовь поспорить первые побежите ставить как только выйдет релиз.

                    Нет. Лучше уж тогда сразу макось или линукс, чем пародию на них.

                    > Я могу вам например дать линк использования pooling при создании игр на XNA и .NET.

                    Бугога)) Сначала они придумывают GC, потом придумывают способ как им не пользоваться.

                    И вообще, все преимущества которые вы тут расписываете, я могу так же применить например к PHP или ruby. Множество библиотек, фреймворков (да-да, со стройными концепциями, вы rails например видели?), автоматическое управление памятью тоже имеется. Только если вы захотите что-то на них написать для десктопа — получится тормозная фигня, как ни оптимизируй. Десктоп — это вам не серверные приложнеия писать, тут свои особенности.

                    • UFO just landed and posted this here
                        0
                        Ни один из аргументов (ну, кроме цифр может быть и тривиальных замечаний) не соответствует реальному положению вещей.

                        Вы тролль-популист?

                        К каждому вашему замечанию выше хочется заметить следующее — «пруфлинк или вы фейл»
                          0
                          … ну в смысле:

                          >> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
                          Пруфлинк или вы — не разбираетесь

                          MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
                          Пруфлинк или вы — не разбираетесь

                          DirectX — нужен для прямого доступа к оборудованию, без него никак
                          Пруфлинк или вы — не разбираетесь

                          … далее вы поняли, куда грести.
                            0
                            >> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
                            > Пруфлинк или вы — не разбираетесь

                            Прежде чем это писать, я не поленился заглянуть в папку TC и посмотреть, какие там есть библиотеки. так же глянул с помощью PeID процесс TotalCmd.exe на предмет того, какие библиотеки в него подгружены (только виндовые станд. библиотеки из system32, довольно таки много, видимо они все тянут друг друга, и несколько плагинов из папки TC для работы с разными архивами, типа UNRAR.DLL и так далее).

                            По слухам, TC писан на Delphi, и довольно таки давно, соответственно Qt/GTK там быть не может (да и gtk под windows работает довольно таки плохо, я бы узнал))). Java/.NET он тоже для установки не требует, и Flash тем более. Да и работал бы он на них хуже и медленнее, трудно было бы не заметить)))

                            к тому же я запускал TC на компьютерах без .NET и Java.

                            Если бы мне очень-очень надо было, я бы мог еще ProcMon просмотреть все файлы, которые он открывает.

                            Какой я тут могу предоставить пруфлинк? Подойти с ножом к автору и грозно спросить, какие библиотеки он использовал? Это же не OpenSource.

                            Или вы мне подкините пруфлинк, что Total commander написан на Java? Но-но, интересно будет почитать.

                            Насчет MFC — там согласен, мутная ситуация, в каких-то версиях windows эти библиотеки есть, в каких-то нет. Тут проще включать dll с программой и не париться. Или как-то без них обойтись.

                            MSVCRT — входит в винду начиная с 98. Пруфы ищите тут: support.microsoft.com/servicedesks/fileversion/dllinfo.asp

                            То же и с остальными. Не вижу никакого смысла искать пруфлинк насчет того, что DirectX предоставляет доступ к видеокарте. Не верите — не надо.

                            По поводу производительности Java/.NET — я тут верю своим глазам а не результатам тестов на выделение объектов, или подсчета какой-нибудь простой функции. Ибо если я вижу что программа тормозит, или требует 30 мегабайтный инсталлятор, или ест 50 мегабайт памяти, или не хочет использовать нативные контролы — это и есть реальный показатель.
                              0
                              >>Не вижу никакого смысла искать пруфлинк насчет того, что 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 гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
                              Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.

                              Я ясно выражаюсь? И есть ли смысл продолжать диалог?
                                0
                                Я охотно поверю, что с точки зрения бизнеса .NET/Java выгоднее (хотя тут еще конечно смотреть надо в каждой конкретной ситуации). Но «выгоднее с точки зрения бизнеса разработчика» != «выгоднее для конечного пользователя», согласитесь?

                                Все мои расуждения — рассуждения с точки зрения «выгодно ли это для меня». Нет, не выгодно. Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится. Или не устанавливать новые версии программ — в принципе думаю года на 3 существующих еще хватит, а там может наконец какую-нибудь хорошую технологию придумают. Слава богу, сегодня нет ни 1 программы на .NET, которая была бы мне необходима.

                                Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic (видимо они посчитали что большинство программистов тупы и C++ не осилят). С одной стороны, повторюсь, я тоже за языки, где не надо руками вызывать delete, и возиться с указателями, конструкторами копирования и прочими ужасами. Но должен ли этот язык быть менее производителен? Не уверен. Должны ли к нему идти громоздкие библиотеки и фреймворки? Не знаю. Должен ли он использовать GC? Тоже не знаю. И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня? И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме? Мне как пользователю нафиг не нужны, уберите их из программы.

                                > Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб.

                                Уверен, размер инсталлятора будет только расти, раньше стремились заполнить CD-диск, теперь на DVD замахнулись, а ведь есть еще Blue Ray((

                                > Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе.

                                Линкуйте против старой версии, в чем проблема?

                                > Простите, не вижу связи между нативными контролами и производительностью. Вы про Java?

                                Я не связывал падение производительности с ненативными контролами (хотя оно подозреваю должно быть). я написал, что мне не нравится как низкая производительность java-программ, так и неуважение к настройкам моего интерфейса. Идея сделать чтобы все программы имели одинаковый look&feel под разными платформами имхо дурацкая, так как всюду эти приложения выглядят не к месту, ими не так удобно пользоваться. Кроме того, дефолтные темы этой граф. библиотеки тоже довольно безвкусны (сан не может найти нормального дизайнера? или как часто бывает у них дизайн рисовали программисты?), что еще больше отталкивает от написанных с ее использованием программ.

                                > На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.

                                Там есть какая-то другая библиотека (JWT? не помню), которая как раз используе нативные контролы.

                                > Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.

                                Ну вот когда у всех уже будет 5 лет стоять виста или семерка (и всюду будут 32-ядерные процессоры), тогда и отношение к .NET может быть у меня будет другое. Но вряд ли.

                                Сейчас такая ситуация, что разработать новую среду/платформу для разработки, может только очень крупная компания, вот и приходится безальтернативно выбирать лучшее из худшего. Либо .NET либо java, либо какой-нибудь с++/Qt (на который вообще наверно сейчас никого не заманишь).

                                вы рассуждаете с точки зрения бизнеса разработчика, я с точки зрения пользователя, вот и вся разница. Пользователю, от того, используете вы MVC и ООП ни жарко ни холодно, а вот если у вас кривой интерфейс, или программа тормозит  — вот от этого уже холодно.
                                  0
                                  >> Но «выгоднее с точки зрения бизнеса разработчика» != «выгоднее для конечного пользователя», согласитесь?

                                  Не соглашусь. весь сервис 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. Так что это не к технологии придирки, а кривым рукам программистов.
                                    –1
                                    > Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.

                                    Какой еще build/deploy/update? Я про программы для нормальных пользователей, а не корпораций, мне не надо обновлять программу, зачем? скачал/распаковал и все, больше ничего не надо.

                                    Вообще, если вы расписывали преимущества дотнета для всяких корпоративных программ. то фиг с ними, там действительно. забота админа ставить фреймворки, и прочее, да и не так жалко на рабочий компьютер все подряд ставить)) Да и корпоративным пользователям обычно не положено кучу программ запускать (обычно офис и какой-нибудь 1с), так что им по барабану сколько программа памяти ест, хоть даже она программа всю память съедает. А вот мне нет.

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

                                    > Беда не в платформе, а в быдлокодерах.

                                    Сделай язык, на котором сможет писать и идиот — идиоты в основном и будут на нем писать. Если дешевле нанять студента/индуса (в переностном смысле, ничего лично против индусов и студентов не имею), их и наймут. Хотя наверно дотнет тут не особо виноват.

                                    > Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.

                                    Если программа из за него не жрет память мегабайтами, и если его поведение/вид не отличается от нативного то да, пофиг. правда думаю, что чем такое качественно реализовать, проще пользоваться нативными))

                                    > Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке.

                                    К сожалению у меня нет возможности проверить, но что-то я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его. Правда, не верится.

                                    Кроме того, непонятно какой смысл компилировать программу в момент запуска. Чушь какая то. Я хочу запустить программу, а не компилировать ее. Почему бы не скомпилировать ее разработчику? Или пусть так уж и быть она компилируется при первом запуске/установке, я не против подождать, если она действительно оптимизируется под мой процессор (опять-таки думаю МС просто лениво было бы делать все эти оптимизации в своем компиляторе).

                                    Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.

                                    В общем ИМХО, байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.

                                    > Поверьте, нужны. Часто их используют не только для интроспекции кода.

                                    Даже если и нужны, наверняка можно сделать то же самое и без них, более эффективно? Ну неужели никак?

                                    > Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)

                                    Возможно, у вас другое понятие «не тормозят». Возможно, вы не спеша любите пофилософствовать пока компьютер «думает». Возможно вы не запускаете больше 1-2-3 программ одновременно. Возможно у вас 2-3 Гб памяти (и программы просто закешированы там, но только после первого запуска). Однако когда много памяти, компьютер будет долго «засыпать»/«просыпаться», а это меня не устраивает еще больше (поэтому у меня памяти мало).

                                    У меня основные программы, плеер, редактор кода, запускаются за секунду, а если они закешированы в памяти то и быстрее. И именно столько времени они и должны запуcкаться а не больше. Смотрите: офис XP, Хром, ИЕ6 (хоть он и плохой, но стартует быстро) — все запускаются быстро, офис к тому же очень экономно относится к памяти (особенно в сравнении с опенофисом). Потому что у их разработчиков руки прямые.

                                    А вот кривы руки у разработчиков Zend Studio (java, запускается до 30 сек.), Komodo (вроде как на XUL, тормозит страшно), FireFox3 (XUL), ну и вообще куча программ сделаны так, как будто для врага писались. Естественно, такие программы либо сносятся мной, либо сразу же запускаются как можно реже.

                                    Еще кстати иногда я пользуюсь фотошопом, но так как он долго запускается (кривоваты руки у адоба видно), я его просто не закрываю, в свернутом состоянии он особо память не потребляет. Зато хоть при работе не тормозит.

                                    Вообще имхо сегодня нет ни одной убедительной причины для не-сверх-сложных программ медленно запускаться или работать, на процессорах делающих миллиард операций (вдумайтесь в эту цифру!) в секунду. разве что игры — но там действительно все очень сложно, много графики, и т.д.

                                    Я пока не видел аналогичных по ресурсам и возможностям программ на .NET или java. увижу — другое дело (но вряд ли это будет) А смотреть на сплеши — это извините возврат к временам Win95. Не для того лучшие умы улучшали 30 лет процессоры, не для того я оптимизировал винду, чтобы я ждал пока что то там запустится.

                                    А возвращаясь к .NET Client Profile — неужели нельзя поставлять с программой только те библиотеки которые реально ей используются? Ну как dll-ки, кинул в папку с программой и не паришься. Или просто лень возиться, проще сразу все 30 мегабайт засунуть? Нафиг такой язык, на котором хелловорд весит 30 мегабайт.

                                      0
                                      Вы ей-б=гу тролль :)

                                      >> Почему бы не скомпилировать ее разработчику?

                                      Читайте выше про оптимизацию

                                      >> Кроме того, подозреваю, что в то время как обычный 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. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
            • UFO just landed and posted this here
                –3
                Зачем мне писать что-то? Сам ты школьник. Посмотри на то что написалим другие: Total Commander, Foobar2000 — вот тщательно написанные программы. Ты можешь такое же на своем дотнете написать? Сомневаюсь.

                .NET — сегодня годится только на сервер.

                Кстати в твоем комментарии, кроме общих слов типа «бредни» ничего нету  — наверно потому что просто сказать нечего по теме.
                • UFO just landed and posted this here
                    0
                    От школьника слышу. На дальнейшие комментарии отвечать не собираюсь.
              0
              В своё время я видел софтину которая позволяла заменять/отцеплять вызовы .Net платформы. Вобщем принцип работы не помню, но она позволяла избавитсья от необходимости поставки .Net платформы вместе с продуктом. Вроде — Salamander .NET Linker and Mini-Deployment Tool. Только она платная.
                0
                Xenocode. но стоит она порядочно, и ключиков мне найти не удалось. но есть evaluation.

              Only users with full accounts can post comments. Log in, please.