>>> timeit.timeit("[1 if x%2==1 else 0 for x in range(100)]") 15.740704012048866 >>> timeit.timeit("[1 if x&1==1 else 0 for x in range(100)]") 14.000356002229637 а на моём компьютере разница минимальна.

Да и то, думаю, реально разницы нету. Потому что интерпретатор этот код одинаково соптимизировал

нормальный компилятор при виде деления инта на 2 сразу решит, что можно вместо этого что-то делать с битами

а в прочем в данном конкретном случае время уходит скорее на работу с памятью, чем собссно на деление

>>> timeit.timeit("for x in xrange(100):x&2") 2.5749120712280273 >>> timeit.timeit("for x in xrange(100):x%2") 3.4274349212646484

мды

чот оно даже не пытается оптимизировать

а в прочем в данном конкретном случае время уходит скорее на работу с памятью, чем собссно на деление

да, байт-код одинаковый получился в моём примере.

а впрочем..

но чот реально время идиотически большое

на С цикл в 100 делений отрабатывает настолько быстро, что time говорит про 0.001 секунды

если распечатывать результаты, то 0.002

и я не очень верю, что питон настолько медленнее

так timeit миллион итераций делает по умолчанию

ага, теперь знаю

>>> timeit.timeit("x%2", "x=1",number=int(1e8)) 5.3698593759120286 >>> timeit.timeit("x%2", "x=2",number=int(1e8)) 9.634653834336433 >>> timeit.timeit("x&1", "x=1",number=int(1e8)) 9.488289771703165 >>> timeit.timeit("x&1", "x=2",number=int(1e8)) 9.287430427221892

$ python -m timeit "map(lambda x: x%2, range(100))" 100000 loops, best of 3: 8.25 usec per loop $ python -m timeit "map(lambda x: x&2, range(100))" 100000 loops, best of 3: 7.18 usec per loop

$ python -m timeit "map(lambda x: x%2, xrange(100))" 100000 loops, best of 3: 7.9 usec per loop $ python -m timeit "map(lambda x: x&2, xrange(100))" 100000 loops, best of 3: 6.92 usec per loop

>>> timeit.timeit("x%2", "x=1",number=int(1e8)) 5.3698593759120286 >>> timeit.timeit("x%2", "x=2",number=int(1e8)) 9.634653834336433 >>> timeit.timeit("x&1", "x=1",number=int(1e8)) 9.488289771703165 >>> timeit.timeit("x&1", "x=2",number=int(1e8)) 9.287430427221892

байт-код отличается только в том, что вызывается BINARY_MODULO или BINARY_AND. Надо лезть в с-реализацию питон-машины, и смотреть какие там есть оптимизации.

когда дебажешь код =) https://vk.com/doc321711679_437340739?hash=c348c8a91ef2bad788&dl=d053b0cdb39da911c7

$ python -m timeit "map(lambda x: x%2, xrange(100))" 100000 loops, best of 3: 7.9 usec per loop $ python -m timeit "map(lambda x: x&2, xrange(100))" 100000 loops, best of 3: 6.92 usec per loop

второй питон?

как я и предполагал, ни select_related, ни prefetch_related кол-во запросов к базе не уменьшили.

а самое смешное, что я даже посмотреть эти запросы не могу, при открытии этой вкладки в DjDT он виснет :^)

дебагер в помощь

кокой?

да, второй. В третьем нет xrange

и блин, в третьем скорость внезапно офигенная

некрофилы должны страдать. :)

а разницы по времени нет совсем или она где-то в другом месте

и блин, в третьем скорость внезапно офигенная

потому что в третьем map возвращает моментально :) оберни в list

$ python3 -m timeit "map(lambda x: x%2, range(100))" 1000000 loops, best of 3: 0.29 usec per loop $ python3 -m timeit "map(lambda x: x%2, range(1000))" 1000000 loops, best of 3: 0.332 usec per loop $ python3 -m timeit "map(lambda x: x&2, range(10000))" 1000000 loops, best of 3: 0.329 usec per loop

а

$ python3 -m timeit "[x%2 for x in range(1000)]" 10000 loops, best of 3: 60.3 usec per loop

$ python3 -m timeit "[x%2 for x in range(100)]" 100000 loops, best of 3: 6.45 usec per loop $ python3 -m timeit "[x&2 for x in range(100)]" 100000 loops, best of 3: 5.26 usec per loop

и все равно быстрее

и все равно быстрее

тут надо нырять в релизацию PyNumber_And и PyNumber_Remainder, но это надо уметь в С исходниках ориентироваться.

а чо там ориентироваться

а чо там ориентироваться

на гитхабе не работает ctrl-click.

там есть поиск

а ваще код конечно нетривиальный

https://github.com/yudisin/cleese/blob/3308482af50344690e5bd615e153ad913731f73f/experimental/pico/python/Objects/abstract.c#L15

тут оно не столько арифметикой занимается, сколько разгребает структуры

в этом файле реализация обоих - разгрести структуры и нужную функцию сунуть в нужный слот

тут оно не столько арифметикой занимается, сколько разгребает структуры

#define NB_BINOP(nb_methods, slot) \ (*(binaryfunc*)(& ((char*)nb_methods)[slot])) у меня от этих двух строк зубы ноют. Я очень давно избегаю смотреть в C код.

да смысл в том, чтобы из массива nb_methods вытащить запись из нужного слота и вернуть в виде указателя на функцию

там ниже еще тонна проверок на тему того, а есть ли она вообще

61 строка, как я понимаю, то что надо.

https://github.com/yudisin/cleese/blob/3308482af50344690e5bd615e153ad913731f73f/experimental/pico/python/Objects/intobject.c

это вытаскивание из слота

а тут по комментам видно, как должны называться функции в слотах вроде бы

(binaryfunc)int_and

эта прямо тут реализована и все почти ок

static PyObject * int_and(PyIntObject *v, PyIntObject *w) {  register long a, b;  CONVERT_TO_LONG(v, a);  CONVERT_TO_LONG(w, b);  return PyInt_FromLong(a & b); }

наёдёшь также про BINARY_MODULO?

PyNumber_Remainder

nb_remainder уже ищу

а, не, тут же - int_mod

static PyObject * int_mod(PyIntObject *x, PyIntObject *y) {         long xi, yi;         long d, m;         CONVERT_TO_LONG(x, xi);         CONVERT_TO_LONG(y, yi);         if (i_divmod(xi, yi, &d, &m) < 0)                 return NULL;         return PyInt_FromLong(m); }

тут есть проверка деления на ноль, а для & такой проверки нету, так что уже прирост скорости

https://github.com/yudisin/cleese/blob/3308482af50344690e5bd615e153ad913731f73f/experimental/necco/python/Objects/intobject.c#L300

ну и в целом код тоже непростой

полностью честно деление делается

так что разница между x&2 и x%2 в том, что первое это (взять из x значение как лонг и потом &2 и потом завернуть обратно)

а второе это еще и куча проверок дополнительных

и последний вопрос: почему 1%2 в два раза быстрее, чем 21%2?

а, еще отдельно там фокус с вычислением % когда кто-то из них отрицательный

21%2`и `22%2 и 2%2 выполняются одинаково по времени.

ERROR: S client not available

делимое меньше делителя, то выполняется быстрее.

а забавный момент

когда при делении может случиться переполнение?

да не, там в C честно деление написано

там нафиг никто не проверяет кто больше, кто меньше

по-моему

посмотреть, что за дупликаты?

посмотрел. сцук, все нужное. но черт, запросы занимают 1 секундк, откуда еще полминуты-то берется при загрузке страницы??

олсо, дупликатами он зовет похожие запросы ну чо я буду делать, если мне нужно запрашивать череду запросов, в которых меняется только номер запрашиваемого элемента ?

посмотрел. сцук, все нужное. но черт, запросы занимают 1 секундк, откуда еще полминуты-то берется при загрузке страницы??

Откуда берётся элемент, который меняется в запросе?

Откуда берётся элемент, который меняется в запросе?

итерируется в цикле

посмотрел. сцук, все нужное. но черт, запросы занимают 1 секундк, откуда еще полминуты-то берется при загрузке страницы??

Выхлоп базы нужно ещё в джанго-модели перевести.

не, я в принципе все понимаю, где что

у меня берется кверисет, для каждого элемента которого в свою очередь тоже берется кверисет, и уже для каждого элемента второго кверисета запрашиваются данные из базы потому так много похожих запросов

посмотрел. сцук, все нужное. но черт, запросы занимают 1 секундк, откуда еще полминуты-то берется при загрузке страницы??

очень часто много времени может занимать трансфер на клиент и рендеринг. у тебя там страница случайно мегов так 10 не весит в итоге?

очень часто много времени может занимать трансфер на клиент и рендеринг. у тебя там страница случайно мегов так 10 не весит в итоге?

неа

каждого элемента второго кверисета запрашиваются данные из базы потому так много похожих запросов вот в место вызова второго кверисета и попрубуй присунуть select_related.

так он принимает только поля отношений. а у меня береутся поля с данными.

select_realated("remote__field1", "remote__field2") (или это в prefetch_related так можно?)

ни селект, ни префетч не поддерживают поля с данными, как я понял из опытов.

олсо, дупликатами он зовет похожие запросы ну чо я буду делать, если мне нужно запрашивать череду запросов, в которых меняется только номер запрашиваемого элемента ?

используя IN ?

используя IN ?

не пони ла

всё они поддерживают. .select_related('front', 'back', 'back__connected', 'front__connected') \ .prefetch_related('back__connected__parent', 'back__connected__parent__parent', 'back__connected__parent__front', 'back__connected__parent__front__connected', 'front__connected__parent', 'front__connected__parent__parent') \

select field1 from table where field2 in ('val1', 'val2')

хм. так. пошел перерывать код.

.select_related('back__connected__parent__parent__name').all()

Cannot find 'post' on Thread object, 'post__post_id' is an invalid parameter to prefetch_related() даже m2o не смог взять.

а просто select_related('post') что покажет?

то же само

ясен пень, что post поля в thread нет. там же обратный ForeignKey. но он его не хочет кушать.

а, вот оно что, надо определить related_name.