Интересно, спасибо. Решил сравнить с PyPy: ➜ ~ time python dict_speed.py
6.94295406342
4.35391998291
4.43011784554
3.0556640625
python dict_speed.py 18,81s user 0,02s system 99% cpu 18,828 total
➜ ~ time pypy dict_speed.py
0.70256114006
0.649827003479
0.807382106781
0.672923088074
pypy dict_speed.py 2,87s user 0,02s system 99% cpu 2,893 total
Не так давно налетели на эти грабли, помимо джанги БД использовалась rails приложением, долго понять не могли почему джанга не видет новые данные добавленные через рельсы. Изначально подумал что где то сидит кэш, но оказалось что проблема совсем иная, после чего наш гуру дал вводный курс по уровням изоляций транзакций =) Так что наматываем на ус и стараемся быть ниндзями, попутно хоть изучая базовые вещи использованных технологий, не всё же кирпичи ставить.
Если брать только платформу windows, то там есть замечательная miranda которая за долгие годы ушла вперед. Из неё можно слепить всё что вздумается (в плане IM), и на мой взгял qutim идет по этим стопам, только не завязываясь на одну платформу.
Вы не забыли что они еще хранят тонны файлов? Боюсь представить сколько huhu занимает места, при этом контент должен быть географически реплицирован, тот же апп стор, хотя тот вроде на амазоне, но думаю эпл в качестве резерва использует. А ведь они имеют десятки крупнейших клиентов, с Большими запросами, поэтому простым смертным туда не попасть.
Я не о том. Для того что бы воспользоваться вашей библиотекой, необходимо заранее при написание кода обеспечить выполнение требования с callback, т.е просто взять обернуть любую функцию не получится. Просто я начал думать как можно обойти это, и не подумал об асинхронных вызовах. А о том где можно применять кэширование результата через return, например у коллекций в backbone есть метод, который хитрым способом делает выборку, и если данных много, и обращений к этому методу, можно было бы делать кэш на пару секунд, но согласен что ситуация высосана из пальца =)
Да, вы правы, не подумал о запросах, тогда надо заранее продумать код под использование кэша, с ходу подключить и пользоваться без внесения изменений не получится.
А нельзя ли избавится от ограничения с callback последним аргументом при помощи декоратора + мемоизаций? Первое что в сонную голову приходит, можно подумать как в декораторе воспользоваться cache(fn)
Предлагаю всё сделать на timecapsule, ну или что то подобное с функцией роутера (круглосуточным аптаймом), глядишь так через пару лет еще и распределенную число дробилку можно будет построить для нужд зла\добра.
Странный да, но в жизни пригодился бы, я бы вообще его не упомянул бы, если бы его реализация не была такой просто и не кому не мешала бы, всё что необходимо сделать это показывать предыдущий номер + сделать его выделенным. Тем кому это не надо будет так же вводить номер словно там всё таже пустая строка, а я буду жать ввод и прыгну туда куда хотел.
Я не поддерживаю выше написанный шантаж =) я вас люблю за ваши продукты, но у меня лично подобное желание возникает пару раз в день, сформулировать почему и зачем сложно, но при отладке и пробеганию по коллбекам это было бы полезно. Монжо сделать эту цифру в поле выделенной, тогда это не будет мешать тем кому это не нужно, а я нажму ввод и попаду куда мне необходимо, главное показывать цифру в зависимости от активного файла. Это такая мелочь, но мне было бы приятно.
➜ ~ time python dict_speed.py
6.94295406342
4.35391998291
4.43011784554
3.0556640625
python dict_speed.py 18,81s user 0,02s system 99% cpu 18,828 total
➜ ~ time pypy dict_speed.py
0.70256114006
0.649827003479
0.807382106781
0.672923088074
pypy dict_speed.py 2,87s user 0,02s system 99% cpu 2,893 total
Ellipsis
. На самом деле слишком поверхностная заметка, есть куда более интересная Стиль кода в языке python via. http://habrahabr.ru/post/76738/cache(fn)
Только чувствую я fn.cache не туда запихнул.