отключать оптимизацию пробовали?
оптимизации там следующие:
-предвычисления
-оптимизации переходов
-превращение глупых вызовов функций в меньшее количество умных вызовов (типа $a=$a+1; превращает в $a++; а в свою очередь $a++; превращает в ++$a; поэтому все оптимизации делаются 2 раза)
-быстрые вызовы стандартных функций
-склеивание блоков
шутка в том что всё это происходит на одном дереве, а значит ситуации когда первый проход склеит кучу блоков в один, а второй «оптимизирует» хитрый условный указатель на этот блок путём дублирования блока — не исключены
на самом деле это тоже оптимизация, но в случае акселератора не контролируется размер дублируемых блоков, поэтому может выйти казус
а возможно я не прав, и бага в чём то ещё
на вашем месте я бы отключил оптимизатор, посмотрел что выйдет и в любом случае постарался бы накатывать новую версию маленькими шажками(если такое возможно) чтобы отловить сначала файл из за которого растёт потребление памяти, ну а потом уже и в файле то же самое чтобы понять причину (вообщем самая настоящая отладка получается)
вы хотите хрень, когда реализуется динамическая модификация базы получается чушь
и да, вам прийдётся хранить хеши полей и пр., но тут уже ничего не поделаешь, так будет быстрее
людям лишившимся руки пока проще сделать пересадку нервов на существующую спинную/брюшную мышцу и снимать показания с неё
снимать показания с мозга весьма сложная задача, но мы работы в данном направлении ведутся
на самом деле не так это дорого и есть именно исследовательская апаратура, а не медецинская
в комплекте шапка на 64 электрода,20 электродов, усилитель и АЦП в одной коробке,USB провод, диск с дровами
мониторить мозг на тему двигания рукой у вас не получится, но можно попробовать закрепить электроды на мускулатуру и снимать показания, напряжённая мышца даёт значительное отклонение на ЭЭГ
не забудьте о том что CRC32 это высокая вероятность коллизий (а значит повторный поиск сравнением) плюс расходы на взятие суммы
стройте B-TREE, не так уж много он пямяти и съест
нет, я ставил на одно дело Яндекс.Сервер а на другое Sphinx и Sphinx мне понравился больше
с яндексовым сервером мы долго бороли проблему падения при индексации очень глубоких ссылок (конкретно не помню, но когда один из файлов базы добирался то ли до 2х то ли до 4х ГБ сервер падал, а при запуске начинал всё индексировать заново, в документации никаких ограничений описано не было, да и вообще с документацией у них грустно)
хотя конечно возможно что Яндекс.Сервер с той поры улучшился(прошло больше года с момента его последнего использования мною)
оптимизации там следующие:
-предвычисления
-оптимизации переходов
-превращение глупых вызовов функций в меньшее количество умных вызовов (типа $a=$a+1; превращает в $a++; а в свою очередь $a++; превращает в ++$a; поэтому все оптимизации делаются 2 раза)
-быстрые вызовы стандартных функций
-склеивание блоков
шутка в том что всё это происходит на одном дереве, а значит ситуации когда первый проход склеит кучу блоков в один, а второй «оптимизирует» хитрый условный указатель на этот блок путём дублирования блока — не исключены
на самом деле это тоже оптимизация, но в случае акселератора не контролируется размер дублируемых блоков, поэтому может выйти казус
а возможно я не прав, и бага в чём то ещё
на вашем месте я бы отключил оптимизатор, посмотрел что выйдет и в любом случае постарался бы накатывать новую версию маленькими шажками(если такое возможно) чтобы отловить сначала файл из за которого растёт потребление памяти, ну а потом уже и в файле то же самое чтобы понять причину (вообщем самая настоящая отладка получается)