А может мне кто-нибудь пояснить, вот пример в конце, он уже ускорен в 4 раза на четырехядерном процессоре или еще что-то надо делать? Еще хотелось бы знать, как erlang работает на windows, каким образом он в одном winapi процессе умудряется делать распаралелливание без тех же winapi потоков? Раскрывается ли erlang на windows?
Большое спасибо! Приятно видеть среди пустых комментариев толковое замечание. Приму к сведению, но переделывать уже не стану. Топик считаю исчерпанным.
Прошу всех не увлекаться и не писать тут про garbage collection и прочие вещи managed кода. Это правда отвлекает от темы. Предлагаю специалистам поднять эту тему в отдельном топике. Мне самому было бы интересно почитать.
Рихтер утверждает, что AppendFormat один из самых часто используемых методов. Значит не критично в принципе. Что касается практики, я провел некоторые эксперименты и убедился что разницы не видно. Наоборот, иногда ваш метод проигрывал по скорости, скорее всего из-за лишнего вызова функции. Впрочем, этот вопрос остается открытым и думаю в разных ситуациях можно применять тот или иной способ.
Не айс. Хотя бы потому что я часто через дизайнер удаляю и добавляю таблицы, следовательно и определения классов будут удаляться и все ваши и изменения в том числе. Никому не рекомендую руками редактировать сгенерированный cs файл DataContext ORM.
Да и главное условие, все исходные коды partial классов должны быть на руках во время компиляции. Нельзя расширить класс имея только сборку где он лежит.
Есть partial классы. Их можно расширять как душе вздумается. Для меня сейчас это актуально в основном для расширения функционала DataContext классов, которые генерируются при создании ORM базы данных (LINQ to SQL classes). Очень удобно расширить объектную модель какой-нибудь таблицы "Cities" методом типа GetCityBanks. А потом писать city.GetCityBanks()...
Беда такого подхода в том, что в итоге мы делаем контрол для включения в другой контрол. Не знаю, насколько это грамотно, но мне лично не нравится. Еще, например в случае установки свойства visible = false для нашего контрола ваш вариант все равно добавит ссылку на js в код. Для того, чтобы отследить эту ситуацию в ваш контрол надо добавлять логику по включению/выключению. Потом, есть смысл отслеживать postback'и. Да еще много чего может понадобится. В итоге, придется сделать ScriptIncluder эдаким ящиком с кучей рычагов, вместо того, чтобы гибко вызывать две функции там где нужно... Я вполне понимаю, что смысл в создании ScriptIncluder есть, но пока я придерживаюсь своего варианта.
А можно поинтересоваться что в данном контексте он (StringBuilder ) даст? По моему создавать такой тяжелый экземпляр класса только для последовательной конкатации строк - это не практично. Есть какие-то особые причины?
Создать контрол на базе моего примера - дело техники. Что касается вашего класса: если вы используете Page, то зачем создавать свой dictionary, свою логику, а не использовать Page.ClientScript и методы которые я привел выше? К тому же, проверьте, что вам вернет Page.Server.MapPath(value)? Используйте ResolveClientUrl. Ну и если мне не изменяют мои глаза этот пример повыводит одни абсолютные имена файлов на сервере, вместо того, чтобы зарегистрировать в head нормальные link на js файлы.
Я тут подумал, еще вчера на Хабре каждый час постились интересные посты и комменты. А сегодня последние несколько часов ничего путного. Суперхабр съел мозги? Народ, давайте продолжать наполнять Хабр смыслом.
"НЛО не допустило вас для участия в эксперименте / UFO has not granted you access to experiment "
:(