Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Етить. А Casus то тут каким боком :) 25 нояб. 2016 г. 9:10 PM пользователь "Naim Shafiev via Moscow-pm" < moscow-pm@pm.org> написал: > да только на версии с grep, но там в modern perl telegram чате петрусевич > побольше чем я занялся ускорение . > вот результаты > Anton Petrusevich: > грубо

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

столько писем в треде и ни одного нормального PoC тест-кейза, где показывается как оно тормозит 5 сек, без всяких cpan модулей и с ip адресами нагенерированными в этом же кейзе. 25 ноября 2016 г., 21:09 пользователь Naim Shafiev via Moscow-pm написал: > да только на версии с

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

да только на версии с grep, но там в modern perl telegram чате петрусевич побольше чем я занялся ускорение . вот результаты Anton Petrusevich: грубо говоря так: когда while( $ipn < $ipn->broadcast ), то вайл занимает 2.2сек; когда my $bc = $ipn->broadcast; while ($ipn < $bc) {, то 1.3сек; когда

Re: [Moscow.pm] Как оформить модуль.

Здравствуйте, Толян. Вы писали 25 ноября 2016 г., 16:45:07: > Существующие обрывают соединение после запроса или вообще делают fork на > каждый запрос. > Поэтому, если хочется посмотреть сайт во Вьетнаме со Вьетнамским > ip, то с существующими проксями бывает очень долго и муторно (пинг ~1 >

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Данных катастрофически не хватает. Судя по первому письму профайлер запускался, но только на версии с grep. Предположу, что map-версия выглядит примерно так: foreach my $iponly (@bla_bla_bla) { my %ips = map { $_ => 1 } @ips; if (not exists($ips{$iponly} )) { return $iponly;

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

25 ноября 2016 г., 15:36 пользователь Naim Sh via Moscow-pm < moscow-pm@pm.org> написал: > @ips даже этим относительно медленным способом > > >while (my $ip = $sql->fetchrow_array) > { > push @ips,$ip; > } > > дает максимум десятки ms задержок и потом уже код который я

Re: [Moscow.pm] Как оформить модуль.

Существующие обрывают соединение после запроса или вообще делают fork на каждый запрос. Поэтому, если хочется посмотреть сайт во Вьетнаме со Вьетнамским ip, то с существующими проксями бывает очень долго и муторно (пинг ~1 секунда). Может минуту загружаться или больше, а чаще вообще не

Re: [Moscow.pm] Как оформить модуль.

On Пт, ноя 25, 2016 в 12:46 , Толян II via Moscow-pm wrote: Есть асинхронный HTTP/HTTPS прокси в виде скрипта + модули. Производительность около 1000 запросов в секунду т.е. очень хорошо. поддерживает HTTP/1.1 --- в том числе постоянные соединения. В работе используется уже

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

по сути лучше не использовать ip адреса в виде scalar string переведи адреса в integer и будет много быстрее. Плюс вместо цикла перебора и поиска можно уйти на Cache::FastMmap и работать через ключи. выборка будет быстрее чем поиск по массиву. On 25.11.2016 15:36, Naim Sh via Moscow-pm wrote:

Re: [Moscow.pm] Как оформить модуль.

github, Dist::Zilla, cpan. Пример оформления: https://github.com/regru/Locale-Babelfish Не факт, что оптимальный, но вроде все просто. 25 ноября 2016 г., 12:46 пользователь Толян II via Moscow-pm < moscow-pm@pm.org> написал: > Доброго времени суток. > > Есть асинхронный HTTP/HTTPS прокси в

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

@ips даже этим относительно медленным способом while (my $ip = $sql->fetchrow_array) { push @ips,$ip; } дает максимум десятки ms задержок и потом уже код который я отсылал . On 11/25/2016 04:16 PM, Толян II via Moscow-pm wrote: У тебя сам цикл тормозит, а не grep

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Тут нужен только List::Util qw( any ). Just fit. 25 ноября 2016 г., 14:00 пользователь Naim Sh via Moscow-pm < moscow-pm@pm.org> написал: > Коллеги, столкнулся с тем что код такого вида , используемый для поиска > свободных ip v4 адресов на размерах 500-1000 элементов отрабатывается под 5 >

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

У тебя сам цикл тормозит, а не grep == use Time::HiRes qw(time); use NetAddr::IP; my @ips = ( map("172.16.1.".$_, 1..254 ), map("172.16.2.".$_, 1..254 ), map("172.16.3.".$_, 1..254 ),

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

ну я бы не сказал. $banned = new Net::Patricia; if(!$banned->match_string($banip)) { $banned->add_string($banip); } просто заполняешь базу Patricia когда тебе нужно и матчишь что есть и чего нет. On 25.11.2016 14:54, Naim Sh via Moscow-pm wrote: да кроме 2 и 3 его нету

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

да кроме 2 и 3 его нету . Кстати как я понял Net::Patricia не очень мне подходит(удобен) ведь мне надо найти адрес которого нет в массиве This module uses a Patricia Trie data structure to quickly perform IP address prefix matching for applications such as IP subnet, network or routing

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

У тебя может быть overload в нескольких местах: 1) В массиве @ips 2) while( $ipn < $ipn->broadcast ) --- вызов метода + overload 3) my $iponly = (split '/', $ipn++)[0]; #get --- overload в чистом виде + преобразование в строку. 25 ноября 2016 г., 14:38 пользователь Naim Sh

Re: [Moscow.pm] Как оформить модуль.

Будет полезна, на cpan. >Пятница, 25 ноября 2016, 12:46 +03:00 от Толян II via Moscow-pm >: > >Доброго времени суток. > >Есть асинхронный HTTP/HTTPS прокси в виде скрипта + модули. >Производительность около 1000 запросов в секунду т.е. очень хорошо. >поддерживает HTTP/1.1 ---

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Привет берем Net::Patricia и переписываем код на неё. Radix Tree рулит! On 25.11.2016 14:00, Naim Sh via Moscow-pm wrote: Коллеги, столкнулся с тем что код такого вида , используемый для поиска свободных ip v4 адресов на размерах 500-1000 элементов отрабатывается под 5 секунд версия с map :

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Оки и какой вариант быстрее того же map будет . код имеет такой вид ( точнее его кусок который больше всего времени и ест ) массив @ips имеет стандартные ipv4 адреса типа 10.56.6.2, 10.135.8.23 , 10.135.22.43 и тд и тп . my $ipn = NetAddr::IP->new("$first_ip/$netmask");

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Добрый день, map будет быстрее только если поисков по одному и тому же исходному массиву @ips будет несколько - т.к. операция построения хэша дорогая. Одноразовый поиск - греп быстрее. first возвращает другое (по смыслу) значение, чем греп (элемент, а не количество), но логически для этой задачи

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

Выглядит не реально, можешь код с данными выложить тем более (500-1000) элементов это ~ 8кб всего. Тестовый пример: == use Time::HiRes qw(time); my @ips = (1..1001); for my $i (0..4){ my $iponly = 995 + $i; my $s = time (); my %ips = map { $_ =>

Re: [Moscow.pm] Очень медленное нахождение элемента в массиве

> под 5 секунд версия с map обычно же map строят заранее. В таком варианте grep будет быстрее. 2016-11-25 13:00 GMT+02:00 Naim Sh via Moscow-pm : > Коллеги, столкнулся с тем что код такого вида , используемый для поиска > свободных ip v4 адресов на размерах 500-1000 элементов

[Moscow.pm] Очень медленное нахождение элемента в массиве

Коллеги, столкнулся с тем что код такого вида , используемый для поиска свободных ip v4 адресов на размерах 500-1000 элементов отрабатывается под 5 секунд версия с map : my %ips = map { $_ => 1 } @ips; if (not exists($ips{$iponly} )) { return $iponly; } и с grep(sic!) ~2 секунду :

Re: [Moscow.pm] Как оформить модуль.

я думаю cpan и github, темболее на гит выложить пару минут пт, 25 нояб. 2016 г. в 12:46, Толян II via Moscow-pm : > Доброго времени суток. > > Есть асинхронный HTTP/HTTPS прокси в виде скрипта + модули. > Производительность около 1000 запросов в секунду т.е. очень хорошо. >

[Moscow.pm] Как оформить модуль.

Доброго времени суток. Есть асинхронный HTTP/HTTPS прокси в виде скрипта + модули. Производительность около 1000 запросов в секунду т.е. очень хорошо. поддерживает HTTP/1.1 --- в том числе постоянные соединения. В работе используется уже года три. Думаю дооформить и выложить на cpan или github.