Dimitry Sibiryakov,

Я еще не встречал компилятор, разворачивающий switch в таблицу и бинарный поиск, а не тупой последовательный перебор. Пример в студию (код, компилятор, опции запуска, ассемблерный файл).

таблицу переходов .

Разницы не замечаете?

Dima T,

Не вижу бинарного поиска в упор.

В Вашем примере бинарного поиска не вижу в упор.

P.S. Читать надо сообщение, на которое отвечаете )))

Dimitry Sibiryakov,
я настаиваю, что, например, при реализации приема команд на AVR по протоколу NEC (8 бит на устройство и 8 бит на команду), перебирать несколько сот кодов последовательно - недопустимая роскошь. Например, восемь устройств по 32 команды. Для 8-битного процессора разница между между 128 и 9 (на порядок!) обращениям к таблице во флеш памяти - грандиозная.

Просто у Вас убогий и совершенно не имеющий практического применения пример. Я же привел пример и собственного опыта. Естественно, редко когда коды команд закодированы последовательно. И тем более нумерация устройств )))

Dimitry Sibiryakov,

никто ничего не запрещает, но код двоичного поиска на порядок меньше занимает места во флеше и на порядок быстрее )))
Когда у Вас 32 килобайта флеша это может влиять вообще на возможность реализации требуемой функциональности на данном МК.
Разбаловались гигабайтами и гигагерцами? )))

Я уже молчу о случае, когда у Вас Padаuk типа PFS154 всего с двумя килословами на борту и 128 байтами оперативки )))

Dimitry Sibiryakov,

прямое.

Во-первых, в приведенном мной примере и был сделан аналогичный сервер на AVR. Не вижу принципиальной разницы в том, что у меня коммуникация по SPI.
Во-вторых, даже на гигабайтах и гигагерцах, при яро пропагандируемом Вами подходе, и получаются монстры требующие по 2ГБ свободной оперативки только для запуска и поедающие до 50% ресурсов многоядерных CPU.

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

Dimitry Sibiryakov,

если чайника-бетонщика учить так, чтобы ему было проще и понятно, то тогда не надо ему штыковать и обрабатывать вибратором бетон при заливке фундамента? Просто залить его на порядок больше, чтобы скомпенсировать отсутствие "оптимизации" объемом? Сами в доме на таком фундаменте захотели бы жить? А программиста так обучать не то что можно, а по Вашим словам - НУЖНО! )))

Что интересно - не от Вас одного слышу такой подход. То есть строителей, врачей, слесарей, сварщиков, автомехаников - так учить недопустимо. Потому что там без "оптимизации" дом рухнет, больной успеет умереть, кран протечет, газопровод прорвет, водитель в ДТП убьется. А программистов - нужно. Комп все стерпит )))

Помнится, именно из-за проблем с отсутствием оптимизации кода пришлось отменить несколько сотен рейсов из аэропорта Хитроу, хотя на тестировании система успешно справлялась с задачей. Но упала под реальной нагрузкой.

Да, если нет никаких следов алгоритмической оптимизации в тысячах методах конкретного программного продукта.

P.S. Вроде бы сайт называется sql.ru. То бишь, люди здесь должны понимать, что подобный код в какой-то CLR может вызываться миллиард раз на одном сервере в одном SQL запросе. Но все равно в лом оптимизировать алгоритм (((

PetroNotC Sharp,

про бетон я в курсе. Оттуда и смайлики, и вопрос о желании жить в таком доме.
И то что оптимизация не всегда нужна тоже в курсе.

Лично меня жизнь болезненными пинками научила оптимизировать код. Сын учится в Бауманке и там студентов заставляют считать, насколько их код оптимален. И от этой оптимальности может зависеть оценка. Что, по моему, правильно. Потому что лучше при обучении заставлять писать оптимально всегда, даже если это не существенно, чем когда слышишь от молодого специалиста: "И так нормально! Я проверял, запрос за секунды выполняется."
И задолбаешся вбивать этому специалисту в голову, что он за секунды выполняется в среде разработки, а на продуктиве через год это может вылиться в десятки минут, негатив от заказчика и ударную оптимизацию в новогодние праздники в честь закрытия года (было и такое).

Ой, спасибо. Промышленный заказчик бы и цента не заплатил, если бы Вы предложили бы ему данные через http гонять по RS-485 )))