xmoonlight, Т.е. наплевать на повторения и попытаться объединить? А какой шанс, что это ускорит дело? И появляется нюанс при сохранении - вдруг глюк. Придется бэкапить старую базу. Нужно попробовать. Сейчас у меня четвертый час идет проверка. Утомила.
А как это ускорит процесс? Не врубаюсь. Т.е. появится куча маленьких массивов, по которым буду прогонять монстра в 400К. Нужно будет проверять по первой группе цифр к примеру а их может быть 255. Т.е. бьём на 255 массивов, которые перебираем. Разве потери времени на это не будут большими? И потом, разве поиск в цикле имеет разницу по времени в зависимости от величины массива? Это in_array накапливает время, а isset одинаково ведет себя. Кроме геморроя тут пока ничего не вижу.
Входящий список - каша. Я уже несколько раз это отметил. Вот как вариант:
173.195.185.35.bc.googleusercontent.com;8080;
Какой тут эррэй уникум справится? Не хочется десять раз все преобразовывать. Хочется одним прогоном разобраться. Задача периодическая, поэтому и хочется ее причесать. По поводу дробления - а чего это даст? Перебор массивов с проверкой значения частями - где шанс, что значение не совпадет в последнем? Я и так брейкую цикл после совпадения.
Проверка ведется параллельно преобразованиям нового списка. Т.е. каждую строку приходится разбирать и пересобирать. Прогонять несколько раз 400К что-то не очень хочется.
Так я беру свою базу примерно 250К и проверяю ее на соответствие новым записям - 400К. Если соответствий нет, то запись добавляется в список проверки, т.е. 250К++ иначе возможны совпадения. Новый список вообще безобразный
Потому что это блоговый движок, на котором понастроили всякого Г... Это все равно, что токарный станок в балетном классе. Опенкарт изначально написан как магазин и не требует молотка и какой-то матери, чтобы заставить его продавать.
Ну, следовательно в контроллере надо смотреть плагина или checkout. Надеюсь вы способны найти catalog/controllers/checkout или папку плагина. Там скорее всего проверка и забита.