Я тоже с этим боролся. Мне будет очень интересно, если кто-нибудь предложит лучший ответ, чем мой, но пока ...
сначала, есть http://www.xn - schler-dya.net/blog/2008/01/15/diffing_json_objects/
Лично мне не удалось заставить эту библиотеку работать, но ваш пробег может отличаться.
Другая альтернатива - не пытаться решить проблему с помощью алгоритма DIFF. Это довольно неэффективно, и в зависимости от проблемы, вы можете получить лучшие показатели производительности, просто отправляя весь блок данных, даже если вы в конечном итоге повторяете себя. Это в основном относится к очень маленьким порциям данных. Очевидно, что наступит переломный момент, так как данные, которые вам нужно передать, станут больше, но не будет очевидным, где находится перелом, без какого-либо измерения. Хитрость в том, что чем больше ваши данные, тем дольше будут выполняться вычисления различий. Поворотный момент определяется только пересечением двух линий, образованных скоростью роста каждого метода, которые будут линейными или хуже, в зависимости от того, как реализован ваш diff. В худшем случае вы можете увидеть остров посередине, где diff получает лучшую производительность, но затем возвращается обратно для еще больших наборов данных, и простая отправка его по сети лучше.
Следующая остановка перед попыткой diff - это завершение доступа к данным в методах «get», «set» и «delete», которые отслеживают внесенные изменения. Данные, которые вы отправляете по проводам, по сути, представляют собой последовательный журнал использования этих методов, который вы сбрасываете со стороны клиента при каждой успешной передаче. На стороне сервера вы применяете этот журнал к вашим данным на стороне сервера с аналогами для ваших методов доступа к данным. Это более легкое решение, чем diff, которое не требует такой большой вычислительной мощности.
Наконец, если вы собираетесь использовать diff, самый эффективный способ, который я могу придумать, состоит в том, можно ли разбить ваш набор данных на отдельные «куски», каждый из которых имеет уникальный идентификатор. Затем, когда вы запускаете различие, его различие находится точно на уровне «чанка». то есть единственное сравнение, которое вы бы сделали, это ID с ID. Если вы меняете чанк, присвойте ему новый идентификатор. Чем меньше вы можете позволить себе сделать алгоритм сравнения, тем меньше времени потребуется для запуска.
В качестве альтернативы, вместо назначения нового идентификатора при изменении, вы можете просто запустить diff, чтобы проверить, изменился ли конкретный объект, остановиться на короткой позиции, как только вы обнаружите изменение, и просто пометить этот чанк для повторного отправлено в полном объеме, чтобы обновить чанк на стороне сервера с тем же идентификатором. Это можно сделать еще более эффективным, если у вас есть какой-то алгоритм быстрого хэширования для ваших чанков, который вы можете использовать для быстрого установления равенства.
Если последовательность ваших чанков не имеет значения, или если вы можете сохранить последовательность как свойство самих чанков, а не смоделировать физическую последовательность чанков, то вы даже можете идентифицировать свои чанки по ID. Тогда для обнаружения различий достаточно просто перечислить ключи объекта A и найти их на объекте B, а затем наоборот. Это гораздо проще реализовать, чем «реальный» алгоритм сравнения, он имеет производительность O (a + b), которая (я думаю) лучше, чем худший сценарий для алгоритма реального сравнения, который вы, вероятно, получите, если пытаетесь реализовать это самостоятельно или получить плохую реализацию.