[Moscow.pm] String to Hash

Kaltashkin Eugene zhecka на gmail.com
Вт Фев 9 01:25:45 PST 2010


09.02.2010 12:13, Михаил Монашёв пишет:
> Здравствуйте, Евгений.
>
> EK>  Хм. интересно получается. SUBSTR всё равно быстрее.
>
> Оно бустрее скорее всего на коротких строчках. На длинных результаты
> бенчмарков могут быть другими.
>    
проверил на 1000 элементах

HASHDOUBLESPLIT:  5 wallclock secs ( 5.12 usr +  0.00 sys =  5.12 CPU) @ 
195.42/s (n=1000)
HASHMAP:  6 wallclock secs ( 5.07 usr +  0.00 sys =  5.07 CPU) @ 
197.23/s (n=1000)
HASHREGEXP:  3 wallclock secs ( 3.21 usr +  0.00 sys =  3.21 CPU) @ 
311.44/s (n=1000)
HASHSPLIT:  3 wallclock secs ( 2.73 usr +  0.00 sys =  2.73 CPU) @ 
366.76/s (n=1000)
HASHSPLITARR:  2 wallclock secs ( 2.70 usr +  0.00 sys =  2.70 CPU) @ 
371.01/s (n=1000)
HASHSPLITCOMMA:  2 wallclock secs ( 2.10 usr +  0.00 sys =  2.10 CPU) @ 
475.84/s (n=1000)
HASHSUBSTR:  2 wallclock secs ( 1.92 usr +  0.00 sys =  1.92 CPU) @ 
520.33/s (n=1000)
HASHSUBSTRINDEX:  2 wallclock secs ( 2.03 usr +  0.00 sys =  2.03 CPU) @ 
492.31/s (n=1000)

Всё равно быстрее. кмк скорее всего из-за использования нативных функций 
поиска элемента в стринге.
Я сейчас пишу редиректор для сквида категорийный с динамическим 
обновлением баз
База доменов я думаю будет записей тысяч в 500-900, нагрузка на 1 
редиректор около 400-500 запросов в секунду по всей базе доменов(хеши имён)
общее количество редиректоров 16 штук. От архитектуры будет зависеть 
насколько быстро сервер загнётся :))
SQL тут будет нервно курить в сторонке кмк.



Подробная информация о списке рассылки Moscow-pm