Форум PHP

Динамически формирую регулярное выражение для проверки телефона

'UKR' => array(             'prefixes' => array('8', '38', '\+38'),             'length' => array(10),         )

если страна Украина например, то берется этот конфиг и с него делается регулярка

/^(8|38|\+38)(\d{10})$/

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

Как ее можно оптимизировать?

кажется я не в ту ветку запостил тему), переместите пожалуйста в Регулярные выражения, у кого есть права)

Большого количества, это в смысле списка номеров и т.п., или это такое количество запросов?

список номеров, эксперементальным методом было определенно, что в 5 мб помещается 50 000 записей(с доп информацией)

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

тестировал на списке номеров в 10 000, он проганяется почти за 10 сек!! + запись в базу = очень долго((

Не надо расчетов сколько во что поместится.
Если у вас уже есть готовый список, это одна проблема, но если это вы добавляете номера в этот список, то трудно представить себе, что вы только после ввода 50000 номеров будете производить запись. Максимум хватит терпения на ввод может быть сотни. И если второе, то почему при записи в базу не происходит их проверка (следовательно в дальнейшем необходимость в ней отпадает), а потом, огромный массив их?

все чуть не так
загрузка будет с csv
есть клиенты, допустим этот клиент загрузил большой список в формате csv, я его сразу в базу отправлять не хочу,
а вдруг там что то не валидное, поэтому пробегаюсь по каждой записи, валидирую их, и всю пачку кладу в отдельную таблицу
помечая строки с ошибками. Потом клиенту делается грид этих данных, типа предпросмотр, где он может каждую запись редактировать.
Когда все ошибки исправлены, он может сохранить этот список(просто переливаем в основную таблицу).

Так вот ограничение я сделал до 5мб, и на этом количестве скрипт завершает свою работу по таймауту, потому нужно оптимизировать узкие места)

>я его сразу в базу отправлять не хочу, а вдруг там что то не валидное, поэтому пробегаюсь по каждой записи, валидирую их

Не кажется ли вам это странным - с одной стороны вы чего-то боитесь, с другой стороны, боясь все таки делаете проверку? Почему же не проверить сразу?

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

Но дело даже не в этом - на кой ляд вообще это нужно, если правила определяет не пользователь а вы? По идее должна быть таблица регионов: Россия, Украина,.... и нужно всего лишь раз проверить (пусть и рег. выражениями) на соответствие региона, помещать принятый номер в базу с указанием региона его (1 - Россия, 2 - Украина, 3 - ....), и возвращать пользователю сразу на редактирование то, что не отвечает условиям?

>Не кажется ли вам это странным - с одной стороны вы чего-то боитесь, с другой стороны, боясь все таки делаете проверку? Почему же не проверить сразу?

>Это на какой-то кошмар похоже, ей богу - вы можете представить себе пользователя, который бы за один раз смог проверить 10000 номеров? Наверное же надо щадить их, и отдавать в таком случае порциями, а это уже гораздо меньшая нагрузка.

ну хорошо, этот момент я еще обдумаю, может вы и правы конечно

>По идее должна быть таблица регионов: Россия, Украина,....

это все есть, и вставляется оно по регионам

но тем не менее, даже если я буду сразу вставлять 10 000 в базу, то они долго обрабатываются и часть вины в этом, судя по всему, в регулярке.

просто если регулярку не получится оптимизировать, то буду что то думать другое
щас добавил игнорирование регистра, но скорости это не добавило

/^(8|38|\+38)(\d{10})$/i

А зачем числам регистр? Код чисел не зависит от регистра.

да, но я подумал что регулярное выражение будет на пару тактов процессора быстрее работать, если явно указать не обращать внимание на регистр)

А что значит не "не обращать внимание на регистр"? Наверное же не плюнуть и принять как есть, так ведь? Не обращать внимание, это значит вычитать из кода "лишние" биты и проверять соответствие, а это время, так что...

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

А с чего вы взяли, что я придираюсь? )
Ну сами подумайте, быстрее ли будет не учитывать регистр, если для этого требуется преобразование каждого байта и его проверка, тем более, что для чисел в этом нет необходимости?

Давайте исходить из того, что большой объем информации неструктурированной и подлежащей обработке, это в любом случае время.
Могу привести пример - мне требовалось из документа Word, представляющего собой перевод с китайского на русский, удалить китайский и английский, а также некоторые символы, затем просчитать длину строки каждой, и в итоге общую длину всех строк.
Сперва документ проходил определенное преобразование, затем разбивался на массив строк, удалялись возможные пустые элементы, а затем в цикле рег. выражениями удалялось лишнее, и производился подсчет.
Максимально полезных строк при этом (*не пустых) было более 3000. И все это происходило быстро.

Но ведь исходить надо не из этого, а из того, что у вас номера. Если бы ваш список был Маша, Даша, Петя, Коля..., согласитесь, что работать с таким списком было бы намного удобнее, чем 23642783423, 538209344... Представьте себя на месте пользователя, смогли бы вы редактируя такой список с огромным числом записей стопроцентно не допустить в нем ошибок? Вряд ли.

Не знаю о чем вы подумаете, но большой массив, это время, а значит нужен диалог с пользователем, и пусть он сразу загружает все, но отдавать ему на редактирование только частями. И делать это можно сразу при приеме документа, а работа на ошибками, это асинхронный диалог с сервером, и пользователю наглядно понятно статус обработки, и ошибок меньше. Ну или потом редактирование частями, правда в этом случае "редактирование", по идее, должно подразумевать нечто иное, например, удаление или добавление одного (нескольких) номеров, редактирование самого номера и т.п..

Вы уверены, что узкое место именно регулярка? Поставьте замеры времени выполнения и потребления памяти в контрольных точках скрипта. Таким образом можно понять какой кусок кода выполняется медленнее всего или потребляет большее количество памяти (или и то, и другое вместе). И тогда можно будет сужать область поиска — расставлять больше контрольных точек в транжирящем ресурсы куске кода. В итоге найдётся бутылочное горлышко, которое требует оптимизации.

PS
Международный код Украины всё же 380, а не 38 :)
Поправьте, иначе есть риск принять сербские (код 381), черногорские (382), хорватские (385) и ещё некоторе другие номера за украинские.