Объединение одинаковых данных и подсчет их(в огромных таблицах)

[Hugo121]

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

[SAS888]

Ну так - яж ещё дополнительно UCase подключил

Согласен. Это обязательное условие автора - сравнивать не зависимо от регистра.
Посмотрите. Я тут тоже "подкрутил" свой код. Сравните время выполнения.

[Hugo121]

Сравнил - да, если я добавлю в конце сортировку, может и проиграю. Но на этих данных (сортировка 8 строк) вряд ли, это надо на практике тестить.
Хотя для ТС доли секунды роли не играют.
И кстати - про регистр ТС ничего не говорил Но по логике конечно регистр не надо учитывать.

[SAS888]

Речь не о сортировке. В моем коде она содержится. Однако процедура выполняется в 2 раза быстрее. Вы обнаружили, почему?

[Hugo121]

Я не обнаружил - у меня она выполняется медленнее моей , поэтому не искал.
Но StrComp() видел, умно - сразу отсекает по первому несовпадению...

[nilem]

Обнаружили. Супер! Что называется, просто и со вкусом.

[nilem]

Сообщение от Hugo121

... у меня она выполняется медленнее моей , поэтому не искал...

Не может быть. Чтобы увидеть разницу, растянул на 150000 строк: мой код 2.03; Hugo 1.82; SAS888 0.59.
Ну и что теперь делать с этими коллекциями/словарями?

Уточнение: 2,03 - это без сортировки. С сортировкой - 2,16 (еще поправил код: массивы не объединяем, а пишем сразу ключ - k = x(i, 1) & x(i, 2)).

[SAS888]

у меня она выполняется медленнее моей

Странно... Результат теста на моем компьютере такой: nilem - 1,25 сек, Hugo121 - 0,98 сек, мой вариант - 0,42 сек. Естественно, в среднем.
По сравнению с 1-м вариантом, я ушел от относительно медленной операции конкатенации и от текстового преобразования LCase (UCase), а так же, проверка 2-го значения делается только при совпадении 1-го. Конечно, при текстовом сравнении (StrComp без учета регистра) все равно происходит текстовое преобразование, но это осуществляется в недрах Windows на языке C, что существенно быстрее.
Но, это все мелочи, по сравнению с тем временем, которое Excel тратит на то, чтобы поместить массив размером 60 000 Х 3 на рабочий лист. Если вы обратили внимание, то в моем последнем примере на лист выводятся только действительные значения (ограниченные наращиваемой переменной j). Пустые, которых в данном примере получается подавляющее большинство, на лист не вставляются.

P.S. Речь идет о тесте прикрепленного файла.

[Hugo121]

Не знаю, у меня вот что на последнем файле Test_1.rar:

nilem 0.703125 сек.
hugo 0.4375 сек.
sas888 0.453125 сек.
nilem 0.6875 сек.
hugo 0.40625 сек.
sas888 0.453125 сек.
nilem 0.6875 сек.
hugo 0.421875 сек.
sas888 0.484375 сек.
nilem 0.703125 сек.
hugo 0.421875 сек.
sas888 0.453125 сек.
nilem 0.703125 сек.
hugo 0.40625 сек.
sas888 0.453125 сек.

Может тут версия влияет - у меня 2000 англ.
Да, про обрезание массива я не заметил. Так и я так могу - ведь есть d.Count

[SAS888]

Может тут версия влияет - у меня 2000 англ.

Да. Очевидно.
Результат еще одного теста:
nilem (2003 рус) - 1,25 сек., nilem (2007 рус) - 1,7 сек.
Hugo121 (2003 рус) - 0,98 сек., Hugo121 (2007 рус) - 1,37 сек.
SAS888 (2003 рус) - 0,42 сек., SAS888 (2007 рус) - 0,52 сек.