Наткнулся я на вот такой замечательный пакет для GO github.com/pmylund/go-cache
Покрутив его мне стало интересно, а что будет если заменить map[string]Item на бинарное дерево, немного повозившись я это сделал и очень обрадовался результатами бенчмарка. Это и стало моей ошибкой.
Бенчмарк показывал среднее ускорение работы кэша почти в 2 раза, вот не сказка ли?
На радостях я тут же оформил пулл реквест (https://github.com/pmylund/go-cache/pull/13), получил ответ pmylund о том, что это выглядит интересно и он подумает.
А я тем временем использовал модифицированный пакет в своем проекте, но закрались в меня сомнения, а действительно ли это так, действительно ли есть прирост скорости в два раза?
И я решил провести небольшое исследование (читай: синтетический тест)
И вот что показали результаты:
Покрутив его мне стало интересно, а что будет если заменить map[string]Item на бинарное дерево, немного повозившись я это сделал и очень обрадовался результатами бенчмарка. Это и стало моей ошибкой.
Бенчмарк показывал среднее ускорение работы кэша почти в 2 раза, вот не сказка ли?
На радостях я тут же оформил пулл реквест (https://github.com/pmylund/go-cache/pull/13), получил ответ pmylund о том, что это выглядит интересно и он подумает.
А я тем временем использовал модифицированный пакет в своем проекте, но закрались в меня сомнения, а действительно ли это так, действительно ли есть прирост скорости в два раза?
И я решил провести небольшое исследование (читай: синтетический тест)
И вот что показали результаты:
Удаление записей
Получение записей
Заполнение
Цикл по структурам
Отсюда, можно судить, при больших объемах бинарное дерево проигрывает по производительности хэшмапу во всем, кроме итераций.
Сами тесты здесь, вместе с графиками
github.com/t0pep0/mb_benchmark
P.S. прошу прощения за несколько сумбурное повествование
ссылка на оригинал статьи http://habrahabr.ru/post/228119/
Добавить комментарий