Исходное сообщение
"JavaScript выбран в качестве основного языка для..." Отправлено arisu, 05-Фев-13 00:33
> но зато программа становится с более предсказуемым поведением дано: цепочка из четырёхсот, например, объектов. односвязный список. и тут головной объект становится сиротой. дальше бедный GC с криками «вперёд! за родину! за сталина!» начинает уменьшать счётчики у всей цепочки. ужасно предсказуемо. а теперь представь сорок тысяч объектов. всё ещё предсказуемо? в данном случае, как ни странно, инкрементальный GC будет намного более предсказуем. а параллельный инкрементальный GC ещё и менее заметен. > а не с зависонами > раз в 30 секунд (ну или как получится) как на Java это тоже решается. и даже в жабке решается. >>> но выше я уже писал что GIL не влияет на системные >>> функции написанные на C/C++ ..). >> угу-угу. ровно до тех пор, пока им не надо обмениться с VM объектами. > ну не идеальная консрукция, да. здесь согласен! :-) и даже не самая лучшая. от «почти полноценного» GC всё равно никуда не делись. > но всё же чем меньше мы будем оставлять циклических ссылок, тем меньше > будет тратится суммарного времени на работу GC в Python. а вот > некоторые другие языки не могут похвастаться этим [говоря про языкы в > которых GC работает без refcounting]. см. выше. ну, и потрать несколько дней, почитай о разных стратегиях сборки мусора, что ли. тогда, возможно, к тебе придёт одно маленькое озарение о возможных причинах именно такой реализации GC в бидоне.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> но зато программа становится с более предсказуемым поведением > дано: цепочка из четырёхсот, например, объектов. односвязный список. и тут головной объект > становится сиротой. дальше бедный GC с криками «вперёд! за родину! за > сталина!» начинает уменьшать счётчики у всей цепочки. ужасно предсказуемо. а теперь > представь сорок тысяч объектов. всё ещё предсказуемо? в данном случае, как > ни странно, инкрементальный GC будет намного более предсказуем. а параллельный инкрементальный > GC ещё и менее заметен. >> а не с зависонами >> раз в 30 секунд (ну или как получится) как на Java > это тоже решается. и даже в жабке решается. >>>> но выше я уже писал что GIL не влияет на системные >>>> функции написанные на C/C++ ..). >>> угу-угу. ровно до тех пор, пока им не надо обмениться с VM объектами. >> ну не идеальная консрукция, да. здесь согласен! :-) > и даже не самая лучшая. от «почти полноценного» GC всё равно никуда > не делись. >> но всё же чем меньше мы будем оставлять циклических ссылок, тем меньше >> будет тратится суммарного времени на работу GC в Python. а вот >> некоторые другие языки не могут похвастаться этим [говоря про языкы в >> которых GC работает без refcounting]. > см. выше. ну, и потрать несколько дней, почитай о разных стратегиях сборки > мусора, что ли. тогда, возможно, к тебе придёт одно маленькое озарение > о возможных причинах именно такой реализации GC в бидоне.
	Введите код, изображенный на картинке: