Соответственно, при наполнении словаря, можно делать раздельно каждый тип запросов (включая xml-rpc). Главное, чтобы памяти хватило на хранение промежуточных результатов.
Я имел в виду запуск скрипта, а не запроса. Если каждый запуск ведёт себя одинаково и не связан с предыдущим, то проблема сужается до анализа php-кода. Профайлер я обычно использую xhprof, но тут уж как кому больше нравится. В любом случае, для задач оптимизации это намного быстрее и эффективнее, чем ручной поиск подозрительных мест. Организовать единый запрос можно двумя способами: через прямой sql (select * fro, b_user where email in (...)"), или через bitrix api, передав в CUser::GetList качестве фильтра email-ов массив (об этом лучше всего спраишвать на соответствующем форуме).
Когда выборка будет получена, нужно её обойти (через GetNext) и записать свойства в словарь, ключами которого будут id или email юзеров, а значениями — формируемые массивы свойств. Потом преобразовать словарь в нужный массив (array_values).
Естественно, это не отменяет возможности выхода из строя микросхем или контроллера по другим причинам, например из-за перегрева, механических повреждений, наводок, пробоев, и так далее.
Во-первых, здесь не нужна абсолютная уникальность. Это будет просто поле для сортировки, а не айдишник. Во-вторых, md5 тоже вовсе не гарантирует уникальность. Кроме того, к примеру, связь номера лотерейного билета по md5 с сортировкой даст одинаковое распределение билетов для каждой лотереи, а это совсем не то, что нужно. А всё потому, что md5 не предназначен для рандомизации.
Кроме случаев, когда программист идёт программистом, но работает не по специальности, про «Какие наиболее идиотские требования к программисту вам встречались», вот:
— почасовое планирование на месяц вперёд всех своих задач, включая оценку рисков (задача для опытного менеджера, а не для начинающего программиста)
— обязательная ежемесячная неанонимная взаимная оценка каждого сотрудника по пятибалльной шкале, от которой зависит премия (как следстие, в том числе и своя)
— умение разбираться в чужом коде, который написан руками из задницы, с примерением всех возможных антипаттернов, без комментариев и табуляции, без правил именования переменных и функций, и с шутками и выпендлежом в коде, примерно в таком стиле «a+=b--?(c>0||d)?k:m--».
— деобфускация слегка обфусцированного кода (см пример выше) под видом рефакторинга
— добавление комментариев в уже написанный чужой код
— обязательное комментривание исправленных и переделанных участков кода специальной «меткой со своим корпоративным логином и датой», которую придумал старший программист, не знающий про VCS, чтобы потом после деплоймента знать, кто накосячил.
Или если программист попадает на должность контентщика (забивает базы данных, управляет админкой сайта, редачит описания товаров, добавляет картинки, и т.д.). И тут его мечты тоже разбиваются, но уже от разочарования в выбранной вакансии.
Если эти части будут участвовать в захлопывании дверей, то идея с направляющими выглядит не очень надёжно. Штырьки отвалятся от механических нагрузок. А если это элемент замка — то, возможно, может и подойти.
Использовать функции и алгоритмы не по назначению — это плохая практика. В противном случае, это может привести к заблуждениям и багам, как например довольно распространена ошибка считать uniqid случайным числом, а на самом деле там закодирован штамп времени, из-за чего возвращаемые строки идут в алфавитном порядке и поэтому могут быть удобны для построения индекса первичного ключа. Хеши предназначены для проверки данных. А для генерации случайного числа есть генераторы псевдослучайных чисел (mt_rand).
Проверил свою теорию: jsfiddle.net/UqYgF/, это действительно не нормально.
Обратите внимание на динамику образования дырок при wrong = true и wrong = false.
Кроме того, ваше условие не сработает, если больше нет элементов с id > $rand.
Как минимум, увеличение шансов на следующий билет при выборе любого билета, так как это образует «окно» в последосательности. И как следствие, увеличение этого «окна», поскольку шанс выбрать нижний элемент будет только увеличиваться при исчерпании билетов. Какие от этого могут быть побочные эффекты для лотереи — не могу сказать, но процесс выбора билетов получается не абсолютно случйный.
