Ключевое в вашей проблеме это — «в эклипсе». Девелопмент сервер отлично перезагружает код после изменения. Не у всех IDE получается с этим интегрироваться.
> В питоне переменная содержащая, например, объект типа int по-умолчанию будет передана по значению, а переменная содержащая объект типа list — по ссылке.
Нет. В питоне всё ссылки, даже int. В питоне есть различие только в mutable/immutable'ности объектов…
Извините, но пока не понимаю о какой поддержке вы говорите. В Джанге, разве там как-то особенно обрабатывается взаимодействие с mod_wsgi? И имеет ли это большое значение при работе проекта?
Как вы считаете, для каких задач оптимальней mod_wsgi, а для каких fcgi?
В lighttpd нет mod_wsgi (а если бы и был по той же архитектуре построен, то обладал бы теме же проблемами что и в nginx только ещё хуже — у лайти один воркер вообще), а в apache да есть, и да работает.
Тут вы совсем не правы. Нельзя сравнивать WSGI и FastCGI — они на разных уровнях ответственности оперируют. Первый это по сути дырка, а второй это провод с переходником который в неё втыкается.
Потом, mod_wsgi в nginx не работает. Вот просто не работает по одной просто причине — любая обработка запрос, которая уходит в mod_wsgi лочит весь воркер nginx. Если для раздачи файлов (а nginx до недавнего времени лочил воркеры и на этой операции из-за синхронного обращения к диску) это не критично, так как файлы обычно маленькие и отдаются зачастую напрямую из файлового кеша OS, то при мало-мальски серьезном приложении внутри mod_wsgi это становится большой проблемой.
> что, понятное дело, убивало все к черту на счетных циклах
Убивало не это, а то что тред, отпустив GIL, мог сам же его снова захватить. Так было из-за того, что он не знает есть ли кто-то другой ждущий выполнения, а OS в свою очередь не успевала в этот интервал переключить контекст.
В новом варианте он отпускает его сам только если флаг выставлен и потом засыпает до того момента как GIL захватит другой тред.
То что всю эту системы перевели на временные интервалы в место числа инструкций, можно сказать, побочный эффект нового подхода:-)
Слишком мало повторений. На таких объемах накладные расходы на переключение GIL не так отчетливо проявляются. А полученный временной результат может зависеть от общей нагруженности системы в какой-то конкретный момент запуска теста.
Суть в том, что треды как минимум не быстрее в CPU-bound задачах.
Есть объект int со значением 1 и на него две ссылки «a» и «b». Cледом создается объект int со значением 2 и в «b» помещается ссылка на него.
Если вы вместо 1 и 2 сделаете список или любой другой объект, то будет тоже самое.
Нет. В питоне всё ссылки, даже int. В питоне есть различие только в mutable/immutable'ности объектов…
Как вы считаете, для каких задач оптимальней mod_wsgi, а для каких fcgi?
Потом, mod_wsgi в nginx не работает. Вот просто не работает по одной просто причине — любая обработка запрос, которая уходит в mod_wsgi лочит весь воркер nginx. Если для раздачи файлов (а nginx до недавнего времени лочил воркеры и на этой операции из-за синхронного обращения к диску) это не критично, так как файлы обычно маленькие и отдаются зачастую напрямую из файлового кеша OS, то при мало-мальски серьезном приложении внутри mod_wsgi это становится большой проблемой.
По этой же причине проект по сути и умер.
Убивало не это, а то что тред, отпустив GIL, мог сам же его снова захватить. Так было из-за того, что он не знает есть ли кто-то другой ждущий выполнения, а OS в свою очередь не успевала в этот интервал переключить контекст.
В новом варианте он отпускает его сам только если флаг выставлен и потом засыпает до того момента как GIL захватит другой тред.
То что всю эту системы перевели на временные интервалы в место числа инструкций, можно сказать, побочный эффект нового подхода:-)
Слишком мало повторений. На таких объемах накладные расходы на переключение GIL не так отчетливо проявляются. А полученный временной результат может зависеть от общей нагруженности системы в какой-то конкретный момент запуска теста.
Суть в том, что треды как минимум не быстрее в CPU-bound задачах.
что вы имеете ввиду?
Лучше вообще взять классический пример с счетчиком:
COUNT = 100000000
CPU_COUNT = 4
def count(n):
while n:
n -= 1
def sequence():
for i in range(CPU_COUNT):
count(COUNT)
def parallel():
pool = []
for i in range(CPU_COUNT):
t = threading.Thread(target=count, args=(COUNT,))
t.start()
pool += [t]
[t.join() for t in pool]
for i in range(2500000):
1000 * 1000
то интерпретатор оптимизирует это выражение и умножения просто не будет при каждой итерации.
добавьте: * i
тогда увидите реальную картину при которой вариант с тредами медленнее.