> Вы извините, но 10 Мб данных сравнивать через for...if - это круто !!! :)
> Спасибо за помощь, но хотелось бы что то поэффективнее.

А для чего, если не секрет, два совершенно одинаковых массива по 10 Мб???

> Вы извините, но 10 Мб данных сравнивать через for...if - это круто !!! :)
> Спасибо за помощь, но хотелось бы что то поэффективнее.

Если массивы так велики, то почему бы не использвать msde?
Скорость сравнения средствами MSSQL с использованием индексов на порядок выше чем в той же джабе.

--
WBR, Roman S. Golubin

M234сравнение массивов, тем более разнородных объектов - всегда перебор.
Не вижу другого пути. Ежели кто знает - поделитесь.

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

www.fun4me.narod.ru>> Скорость сравнения средствами MSSQL с использованием индексов на порядок выше чем в той же джабе.

Скорость будет ниже, потому что MSSQL не учитывает порядок элементов в массиве. Здесь сложность o(n). А в MSSQL будет o(n*log(n))

Т.е.? Ты считаешь, что простой перебор быстрее сравнения по индексам?

Например:


где FK_arr_val - форент на массив значений (я думаю, несовместимые друг с другом объекты ты сравнивать не собираешься?)

Да, совсем забыл - первичный ключ тоже надо включить в индекс:

select @c1 = count(*) from arr1 inner join arr0 on (arr0.FK_arr_val = arr1.FK_arr_val and arr0.PK = arr1.PK)

www.fun4me.narod.ruПлюс, когда мы делаем

select @c1 = count(*) from arr1 inner join arr0 on (arr0.FK_arr_val = arr1.FK_arr_val)

Мы должны перебрать все элементы массива arr1 хотя бы один раз. Разве нет?

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

Aleksey_tХааа, перебирать то мы должны индексы, но ~ 4 байта это ~ ссылка на данные в карте записей, а размер ключа индекса равен размеру полей по которым индекс построен :) Если не верите, почитайте в MSDN, кстати обычные индексы в MS SQL созданы на основе улучшенного B-дерева.
Так что в любом случае мы должны перебрать все элементы массива arr1 хотя бы один раз.

Хмм... я представляю себе табличку (или даже набор табличек), в которых лежат записи о каких-то объектах, и у которой есть сурогатный первичный ключ (4 байта). Массив создается добавлением ссылки на сурогатный ключ в таблички arr0 и arr1. После этого соответствие массивов легко проверяется по индексу, построенному по 4-х байтному полю.

PS: На самом деле, я не могу представить себе задачи, где пришлось бы более бестолково сравнивать два массива по 10 метров. Я еще мог бы понять, если бы было нужно найти, например, с какого места они начинают расходиться. Но просто сравнить??!! - ну, допустим, они не равны - какое знание ты получишь из этого? А если равны, то что тогда?

PSS: Ты так и не сказал, что за данные находятся в этих массивах. Если там отсутствуют хоть какие-то метаданные, то это просто бредовый набор данных. Смысла сравнивать его с чем-либо, имхо, нет ни какого. Если метаданные есть, то это прямой кандидат для создания базы данных, раскладки содержимого по таблицам и сравнения посредством запроса, указанного мною выше.

--
WBR, Roman S. Golubin

Aleksey_tДаа, я одну деталь упустил (т.к. надеялся что в шарпе есть что то типа джававского Array.Equals). Данные однородные: массив байтов.
И судя по всему другого варианта нет как простой перебор.

Тестим:


Результат: 00:00:00.0801152

Скорость сравнения примерно 120 метров в секунду. Не впечатляет?
И это на смешном ноутбуке... полностью два едентичных массива по 10 метров. Если бы расхождение было в первом мегабайте, то таких проверок можно было бы делать от сто штук в секунду :-))

--
WBR, Roman S. Golubin

PS: А я, думая, что ты сравниваешь сложносоставные объекты, начал еще распинаться про msde :-)