AVK>Встроенный маппинг, который тормознее BLT? Нет, это маппинг рукопашный. И RFD не для улучшения его производительности создавался, а для уменьшения количества ручной работы. И эмит (ты, видимо, его имеешь ввиду) там использовался как единственная альтернатива рефлекшену, для которого заранее было известно, что производительность его неудовлетворительная, а не для битовыжимания в качестве основной цели.
"По быстрому" там делается за один вечер на коленке через генерацию исходников (что у нас и было вначале, ибо NHibernate и прочее не были еще даже и в альфе, а были только вот такие же наколенные поделки, не лучше нашей).
Но суть позиции мне непонятна все-равно. Ты рядом написал "верю", хотя я и сказал о разработчиках с опытом (неопытных надо не ругать а учить, или увольнять в клинических случаях). Почитать вот эти все советы, так начинает казаться, что опыт — это всего лишь приобретенная осторожность, вот мол, не делайте лишней работы и прочие сопли. Дудки, опыт — это прежде всего адекватная оценка собственных знаний и способностей. А это значит, что где знаний достаточно — наоборот нужно быть как можно более решительным и заранее отметать тупиковые варианты, проявляя осторожность лишь там, где информации/наработок недостаточно. Иначе бенефитов от опытности не будет, если каждый раз заново все макетировать, чтобы ни дай бог написать чего лишнего. Понятно, что там не только "черное и белое", "знаю/не знаю", главное — уметь правильно себя на этом градиенте спозиционировать относительно решаемого вопроса.
Так вот, раз уж сказано почти все, могу и открытым текстом: все откровенно выглядит так, будто кое-кто отказывает коллегам в способности принимать решения, не отказывая в то же время самому себе, любимому. И Дворкин здесь выглядит как классический мальчик для битья, если ты понимаешь о чем речь.
Здравствуйте, Silver_s, Вы писали:
S_>А что касается студентов, им очень полезно в битовыжиманиях поупражняться.
+1
Мне тоже так кажется, мозги полезно поупражнять в нужном направлении, особенно на тех задачах, которые понимаешь полностью... ИМХО, улучшение производительности через "повышение эффективности архитектурных решений" вряд ли осилит больше, чем 1-2 человека на потоке, и то, если повезет, ибо без реальной практики все эти слова — пустой звук.
V>Я ее всю не осилил, ибо слишком много уже было подобных дискуссий, можно чуть конкретнее, чтобы было видно, что оппонент "загоняет"?
Там все не надо, вот, краткое содержание
PD>Если не секрет, объясни, как реализовать обращение к этому Last в процессе обычной энумерации. То есть идем себе и идем по коллекции, потом захотели Last, а потом продолжаем идти с того места, где остановились... Чудо, а не код получится S>Никаких чудес. На всякий случай напомню, что IEnumerable — это всего лишь способ получения IEnumerator. И у одного IEnumerable можно получить сколько угодно одновременно активных енумераторов. PD>При открытии файлмэппинга никакой IEnumerable получить нельзя, потому что нечего энумерировать. S>Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать. PD>Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше. AVK>Аргумент. PD>Так что, как видишь, аргумент вполне обоснованнный. Если не согласен — поясни, как их к обычному С++ прикрутить. FR>Да нормально они к C++ прикручиваются, я подобные классы еще когда NET не было использовал: PD>Речь идет об интерфейсах. Их в языке С++ нет.
Вот теперь сравни начало и конец. И везде гд учавствует Дворкин, такое на каждой странице.
V>Да, промахнулся, там ниже пост IT, который сравнивал "битовыжимание" с другими качествами преподавателя. Хотел показать как пример, где весь пост — суть игра терминов.
Битовыжимание у Дворкина, он готов буквально этим заниматься.
V>Мне, если честно, плохо понятен термин "битовыжимание". Я понимаю, что туда вкладывают много негатива, но хотелось бы достоверных
доказательств, что весь этот негатив применим к оппоненту, т.е. что не используется банальное развешивание ярлыков. Мой поинт таков, что если задачи требуют "битовыжимания", значит закатили рукава и битовыжимаем.
Если
1 задача требует,
2 место, где используется эта самая задача является узким местом
3 на все это установлен соответствующий приоритет
4 есть время для устранения сайдэффектов которыми богато битовыжимание
— то нужно заняться битовыжиманием.
V>Поэтому, ключевое слово здесь не "битовыжимание", а "требуется/не требуется", только вот об этом и можно рассуждать.
Разумеется и вот здесь у Дворкина начинаются сильные проблемы — он отказывается принять точку зрения отличную от его собственной.
Требования везде разные. Всегда нужно учитывать баланс между производительностью, стоимостью работ и временем работ.
Я как то не заметил такого у Дворкина. Он праведно возмущается при любом проявлении неэффективного кода.
V>Ну, если не в курсе, разработка его BLT ORM (тогда еще RFD) началась с того, что IT экспериментировал с "битовыжиманием" относительно реализации аксессоров для полей и св-в в системе .Net. Эксперимент вышел более-менее удачный, и дальше пошло-поехало.
Акцессоры для полей-свойств часто становятся самым узким местом в системе. Если взять например persistance то здесь получается выбор решения определяется именно скоростью доступа к свойствам-полям.
Например при высоких требованиях к скорости этого персистанца получается так, есть быстрый доступ — тогда можно взять простой обход графа объектов. Есть только медленный — тогда уже нужна генерация кода например или сложная какая схема. Тут сложности разница примерно на два порядка.
