ну он всё таки оптимизатор, а не "смотровая щель"

ага

нашёл версию: из-за того, что он видит больше инструкций одновременно, чем компилятор во время генерации кода

ну, в peephole часто за раздетыми подсматривают... т.е. оно смотрит на голый байткод. вечная шутка про синонимы bare и naked

в git же можно вместо git clone --bare написать git clone --naked :)

примерно как разница между раздетый и неодетый...

псс.. есть xslt либа для json? )

хм

а зачем?

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

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

ну, json->xml->xslt->xml->json :)

я так и подозревал почему-то

внезапно http://stackoverflow.com/questions/1618038/xslt-equivalent-for-json

не xslt но может упростить http://sedimental.org/remap.html

https://stedolan.github.io/jq/ sed for json :)

ну jq я пользуюсь периодически

внезапно http://stackoverflow.com/questions/1618038/xslt-equivalent-for-json

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

но как я понимаю вопрос был про либу для python

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

ну, там самое живое на java

ну, там самое живое на java

а где же ему еще быть то ))

вообще, прежде всего, json слишком гибкий, чтобы можно было легко программно проверить корректность конкретной трансформации

если не грузить в объекты, то всё сложно

не xslt но может упростить http://sedimental.org/remap.html

Спасибо, похоже на то что надо

имхо, самое надежное - налабать свой на ноде или поискать для ноды

там хотя бы не будет преобразований регекспами и перкладывания между разными способами представления

ну собственно, очевидно, что оно уже должно было быть https://www.npmjs.com/package/node-json-transform

что-то не охото мне пока node тянуть на прод

а зато как няшно на колбэках можно было бы проксю сделать;)

колбеки? зачем es6 же async )

и скачи оно конем

колбеки? зачем es6 же async )

ну да, ну да:)

вот так поешь пиццу с человеком, а он потом тебя в твои же слова тыкать будет...

python 3.5 + uvloop + httptools || pypy + gevent

ну вот pypy все портит;) если бы не он, то gevent в топку:)

а, кстати, uvloop же в 3.6 хотели притащить...

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

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

я когда с svn на git перелез только, пугался git checkout <branch>, потому что он работал сразу, меня это пугало;)

неа, uvloop не даёт ускорения для aiohttp

https://hsto.org/getpro/habr/post_images/734/695/087/7346950870f6b561274c9f62d351acf5.png

https://hsto.org/getpro/habr/post_images/734/695/087/7346950870f6b561274c9f62d351acf5.png

: ) видимо там россыпи питонокода мешают

https://hsto.org/getpro/habr/post_images/734/695/087/7346950870f6b561274c9f62d351acf5.png

https://gist.github.com/pfreixes/a863eefab923e2addb00d6561901f915

: ) видимо там россыпи питонокода мешают

>However, the performance bottleneck in aiohttp turned out to be its HTTP parser, which is so slow, that it matters very little how fast the underlying I/O library is.

который на питоне же, да?

не, там всё интереснее )

чпок http://aiowsgi.readthedocs.io/en/latest/

https://github.com/KeepSafe/aiohttp/issues/858

который на питоне же, да?

но в целом да, тормозит из-за питона )

https://github.com/KeepSafe/aiohttp/issues/858#issuecomment-217771873

вот тут подробно

но в целом да, тормозит из-за питона )

ну я вот код aiohttp.web вспомнил и сомнений не было

и ни одного flamegraph в тредике. чем они там занимались вообще?

Возвращаясь к той задачке с облаком точек, сделал пару вариантов: "в лоб" и с использованием равномерной сетки. Вариант с сеткой работает быстрее, когда много данных, но выдаёт худший результат с точки зрения распределения точек в прореженном облаке. Оба варианта не справляются с миллиардом точек. 10_000_000 точек вариант с сеткой на моём i7 считает ~30 сек. Вариант без сетки ~50 сек. А код такой получился. https://gist.github.com/espdev/a16f28be634c3c4999d5053ac5d50710 В общем, надо придумывать что-то ещё...

Для миллиардов точек сама структура KD-Tree уже работает слишком медленно. По крайней мере её Cython-реализация cKdTree в Scipy.

а без него нельзя?

Без KDTree?

да

Не знаю. Может и можно. Но как ещё быстро искать соседей? R-Tree или R*-Tree работают примерно с такой же скоростью.

Не знаю. Может и можно. Но как ещё быстро искать соседей? R-Tree или R*-Tree работают примерно с такой же скоростью.

Напомни, пожалуйста, что сделать надо

Есть такой вопрос: Существуют ли эффективные алгоритмы для решения задачи прореживания облака точек в N-мерном пространстве по минимальному радиусу? То есть надо проредить облако точек так, чтобы расстояние между точками в облаке не было меньше заданного? Например, с использованием струкутры KdTree или ещё как-то? Точек могут быть миллиарды. Есть оптимальный алгоритм решения подобной задачи и какая наилучшая/наихудшая сложность у него?

.

Не знаю. Может и можно. Но как ещё быстро искать соседей? R-Tree или R*-Tree работают примерно с такой же скоростью.

Не смотрел на https://en.wikipedia.org/wiki/Fixed-radius_near_neighbors ?

по ощущениям человеку хочется рисовать диаграммы вороного в пространстве

по ощущениям человеку хочется рисовать диаграммы вороного в пространстве

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

Не смотрел на https://en.wikipedia.org/wiki/Fixed-radius_near_neighbors ?

Спасибо, посмотрю

Получилось поднять Klein на Blackswift. пришлось подключить флэшку, потому как 16мб места было очень мало.

ERROR: S client not available

Connection:keep-alive Content-Type:text/html Date:Thu, 22 Sep 2016 00:53:04 GMT Server:TwistedWeb/16.4.1 Transfer-Encoding:chunked

Содственно вот. http://kntchk.com/

Connection:keep-alive Content-Type:text/html Date:Thu, 22 Sep 2016 00:53:04 GMT Server:TwistedWeb/16.4.1 Transfer-Encoding:chunked

Омг

Омг

А что не так. Не силен в этом

?

Я про запуск твистед на такой железке :)

https://twitter.com/asmeurer/status/778815696775974913

граждане, а кто какими реализациями prefix trie пользовался?

https://twitter.com/asmeurer/status/778815696775974913

Да чтож такое то?? Перешел по ссылке и минут на 20 залип в этот ваш твитур

Benchmarks show that prefixtree is 200 times slower than the builtin dict and requires 10 times the memory.>

коллеги, держаться больше нету сил. кто еще Sentry использует? sentry upgrade 4 часа, "бомба продолжает прыгать" есть ли известный способ выполнить апгрейд без всякого лишнего шлака, типа "fixing number of comments counters"?

попадалово

вопрос. запускаю python скрипт. Он работает у себя в фоне. Допустим я поменял что-то в нем. и хочу перезапустить, можно ли как-то сказать python перечитать файл заново? не прибивая процесс?

вопрос. запускаю python скрипт. Он работает у себя в фоне. Допустим я поменял что-то в нем. и хочу перезапустить, можно ли как-то сказать python перечитать файл заново? не прибивая процесс?

Добро пожаловать в клуб

ок :(

Ну, всякие manhole и reload в помощь

В IPython есть autoreload, например http://ipython.readthedocs.io/en/stable/config/extensions/autoreload.html

граждане, а кто какими реализациями prefix trie пользовался?

marisa_trie

вопрос. запускаю python скрипт. Он работает у себя в фоне. Допустим я поменял что-то в нем. и хочу перезапустить, можно ли как-то сказать python перечитать файл заново? не прибивая процесс?

для такого скрипт надо грамотно писать еще

для такого скрипт надо грамотно писать еще

уже почитал. решил проблему через bash. =)

там можно и не грамотно )

там можно и не грамотно )

я про то что релоад не затронет созданных объектов

Насколько я понял, просто стоит вотчер на баше, который супервизит python скрипт и перезапускает его. Кстати можно было через gunicorn запустить там есть авторелоад

не, ну это перезапуск скрипта. а тут как я понял хотелось горячую замену кода

import foo ... reload(foo)

в тройке релоад уехал из встроенных в importlib

а всякие гуникорны и иже с ним делают форк - родитель тупо перезапускает скрипт заново, пока не получит код завершение, а в порожденном процессе крутится тред, который эпизодически сверяет mtime'ы файлов, которые дергаются из sys.modules.values() -> __file__ если хоть чтото поменялось - процесс дохнет и родитель его заводит заново

а всякие гуникорны и иже с ним делают форк - родитель тупо перезапускает скрипт заново, пока не получит код завершение, а в порожденном процессе крутится тред, который эпизодически сверяет mtime'ы файлов, которые дергаются из sys.modules.values() -> __file__ если хоть чтото поменялось - процесс дохнет и родитель его заводит заново

ну да, тогда уж лучше docker

import foo ... reload(foo)

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

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

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

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

есть и готовые решения.

от архитектуры зависит