Коммивояжер и карта / сокращение: отказаться от канала

Это скорее академический, чем практический вопрос. В задаче коммивояжера или в любой другой задаче, требующей минимальной оптимизации ... если бы кто-то использовал подход map / reduce, кажется, что было бы некоторая ценность в наличии некоторых средств для передачи текущего минимального результата на все вычислительные узлы каким-либо образом, что позволяет им отказаться от вычислений, которые превышают это.

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

Один подход, который сразу приходит на ум, быть, если редуктор имел средства для обратной связи с картографом. Представьте, что у нас есть 100 узлов и миллионы путей, передаваемых к ним картографом. Если редуктор передает лучший результат в преобразователь, то это значение может быть включено в качестве аргумента вместе с каждым новым путем (проблемное подмножество). В этом подходе степень детализации довольно грубая. ... каждый из 100 узлов будет продолжать работать над своим разделом проблемы до завершения и получит новый минимум только со своим следующим запросом от картографа. (Для небольшого количества узлов и огромного количества проблемных разделов / подмножеств работа с этой степенью детализации будет несущественной; также вероятно, что можно было бы применить эвристику к последовательности, в которой возможные маршруты или проблемные подмножества передаются узлам для получить быструю сходимость к оптимуму и, таким образом, минимизировать количество "бесполезных" вычислений, выполняемых узлами).

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

Недостаточно памяти (выделено 22544384) (попытка выделить 232 байта)

Это довольно неприятная проблема для отладки, так как у меня мало информации о том, что вызвало проблему.

Добавление выключения функция помогла

register_shutdown_function('shutdown');

тогда, используя error_get_last (); Я могу получить информацию о последней ошибке, в данном случае о фатальной ошибке «Недостаточно памяти», например о номере строки и имени файла php.

Это хорошо и все такое, но моя программа php сильно объектно-ориентирована. Ошибка глубоко в стеке мало что говорит мне о структуре управления или стеке выполнения в момент возникновения ошибки. Я пробовал debug_backtrace (), , но это показывает мне только стек во время выключения, а не стек во время ошибки.

Я знаю, что могу просто увеличить лимит памяти с помощью ini_set или изменения php.ini, но это не приближает меня к фактическому выяснению того, что потребляет так много памяти или как выглядит мой поток выполнения во время ошибки.

У кого-нибудь есть хорошая методология для отладки ошибок памяти в расширенных объектно-ориентированных программах PHP?