[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