user7320,

мне кажется, что это вы не понимаете ответов, которые вам озвучивают.

На .Net нет языков, позволяющих управлять железом на уровне ассемблера. Компилятор сам выбирает нужное множество команд процессора. И сам рулит размещением данных в регистрах. А "конвейер команд" в применении к .Net вообще выглядит смешно. Код в любом языке будет исполняться быстрее, если там мало ветвлений. Тогда больше шансов на то, что процессор сможет предугадать следующие команды.

Что касается скорости, то один громоздкий метод будет работать быстрее, чем он же, декомпозированный на тысячу методов. Переход из метода в метод - не самая быстрая операция в .Net

Если у вас какая то мания насчет сверхскорости исполнения задач, переходите на чистый C/С++. Преимущество dotNet не в сверхскорости работы программ, а в сверхскорости разработки этих программ.

user7320Т. е. никаких рекомендаций про мой первоначальный вопрос дать в мире Дотнета нельзя? Хошь, цельный объект передавай. Хошь, по частям. Всё равно мой код пройдёт через такую кучу интерпретаторов-компиляторов, а возможности котроля не то, что ограничены, а вообще отсутствуют, так что как-то повлиять на конечный результат не представляется возможным?

почему ж...

1) какой бы не был размер объекта, передача его по ссылке займет одно и тоже время. Ведь указатель - это число.

2) какой бы не был размер объекта, компилятор в режиме релиза попытается оптимизировать ваш код (то, что вы делаете с объектом уже в методе). Скорее всего, все переменные метода, а также часть настроек, с которыми вы работаете, будет раскидана по регистрам процессора. Если вы работаете с этим объектом и не спешите передать его в GC, то какая то часть обязательно попадет в кэш процессора. Но большинство данных программы будет располагаться в оперативке.

3) явно рулить тем, что и где должно быть, просто из .Net вы не сможете

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

Вы знаете, что оптимизатор SQL сервера в принципе очень даже интеллектуальный? Для управления процессом исполнения запросов MS SQL дает кучу всевозможных опций для оптимизации. Но попытка ими воспользоваться даже для разработчика средней руки приведет только к отрицательным последствиям. Уж слишком узкозаточенным получается запрос. Шаг в сторону - и даже правильно написанный код исполняется в сто и более раз медленнее. А уж переход с версии на версию приводит к мучениям.

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