О прожорливости питона

> массив из 100млн элементов размером 4 байта уместился в 300кб?

Где?

а быстрее процессора питон работать не умеет случаем? или хотя бы бесконечный цикл выполнить?

Опять пропустил прием лекарств?

а туплю

у меня жрет 200

$ /usr/bin/python
Python 2.5.1 (r251:54863, Sep  1 2010, 22:03:14) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     def __init__(self, a, b):
...             self.a=a
...             self.b=b
... 
>>> s = 1000000
>>> l = [1] * s
>>> for i in range(s):
...     l.append(A(i, i+1))
... 
>>>  
[1]+  Stopped                 /usr/bin/python
$ ps -o rss,command | grep Python
217120 /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python

макос не мой, я просто разместил объяву

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

++

>Почему оно PHPшное? В реальных программах вполне может понадобиться постепенно добавлять элементы в список.

Для ускорения работы если ты делаешь append в массив, а память не выделена, то выделяется не для одного элемента, а выделяется под 2-х кратное увеличение. Толи на активстейт, толи где еще было написано почему так. Это увеличивает производительность реальных софтин.

Для молотилки таких объемов вообще нормальные люди используют mmap

for i in range(100000000):

xrange для кого делали? Документацию для кого писали?

Он уже несколько раз писал, что питон 3...

Может тебе еще подсчет ссылок в C++ реализовать, чтобы было как в питоне? Есть задача — организовать хранение большого количества объектов. Я сделал это так как это оптимальнее сделать в C++.

Твое же требование «сделать как в питоне» — все равно что при сравнения схемы и C требовать чтобы в C циклы организовывались в виде рекурсии. То что в питоне нет хранения по значению, и на каждый объект вызывается аллокатор — это проблемы питона.

Если у тебя есть предложения, как сохранить миллион восьмибайтовых объектов в питоне так, чтобы они заняли 8 мегабайт, озвучь его.

> Твое же требование «сделать как в питоне»

Да, это я сглупил. Ты не знаешь Питон, и требовать от тебя «сделать как в Питоне» бессмысленно.

Если у тебя есть предложения, как сохранить миллион восьмибайтовых объектов в питоне так, чтобы они заняли 8 мегабайт, озвучь его.

Тебе уже много раз сказали - array.

>Тебе уже много раз сказали - array.

array — Efficient arrays of _numeric_ values

Ты не знаешь Питон, и требовать от тебя «сделать как в Питоне» бессмысленно.

Вот и пошло применение «правил демагога». Молодец, я в тебе не сомневался.

Если у тебя есть предложения, как сохранить миллион восьмибайтовых объектов в питоне так, чтобы они заняли 8 мегабайт, озвучь его.

As you wish.

import struct

st = struct.Struct('=ll')
s = 1000000
wbuf = bytearray(s * st.size)
for i in xrange(s):
    st.pack_into(wbuf, i*st.size, i, i+1)

rbuf = buffer(wbuf)
print st.unpack_from(rbuf, 100*st.size)

input()

Ну че уже лучше. Правда если понадобится добавить в этот struct методы, наследование, поля отличные от численных то ничего не получится.

> array — Efficient arrays of _numeric_ values

Можешь занести туда любые двоичные данные.

Ты не знаешь Питон, и требовать от тебя «сделать как в Питоне» бессмысленно.

Вот и пошло применение «правил демагога».

Это очевидный факт.

Молодец, я в тебе не сомневался.

А я и не собираюсь притворяться кем-то другим.

>Можешь занести туда любые двоичные данные.

Объекты сериализовать что-ли? Тогда все преимущества быстрой разработки теряются.

Правда если понадобится добавить в этот struct методы, наследование, поля отличные от численных то ничего не получится.

Ты даже на C++ хранишь в памяти миллионы объектов с «методами, наследованием, полями отличными от численных»?

Никогда такого не хотел делать. И никогда не понадобится.

Если это понадобится, то будет выглядить красиво и понятно, а не так как в твоем коде.

а не так как в твоем коде

По своей воле я такой код никогда не напишу. Пойнт, который тебе пытаются донести на протяжении всего треда — в питоне данные можно (сюрпрайз!) хранить компактно, но обрабатывать на нем гигантские массивы из сложных объектов никто в здравом уме не будет, для этого как бы есть другие инструменты.

Питаются главным образом млекопитающими (крупные питоны заглатывают шакалов, молодых леопардов, дикобразов, молодых кабанов и т. д.), а также птицами, крупными ящерицами; молодые питоны поедают мелких грызунов, ящериц, реже — лягушек. Добычу ловят, хватая её зубами и одновременно сжимая кольцами своего тела. Добыча заглатывается целиком, чему способствует строение челюстного аппарата змей. Питоны способны заглатывать очень крупную добычу, а затем переваривают её в течение довольно длительного времени, но могут подолгу (до 1,5 лет) обходиться без пищи.

P.S. Тред не читал.

class STRUCT(Structure):
    _fields_ = [("a", c_int),
               ("b", c_int)]
    def foo(self):
        print(self.a, self.b)

Как один из вариантов представления бинарных миллионных данных из буфера. Методы есть... все есть.

>Пойнт, который тебе пытаются донести на протяжении всего треда

Топикстартеру нужны были причины прожорливости питона, я их показал (огромный оверхед на служебную информацию — плата за удобство языка). Но питонисты стали доказывать что это не так.

Толи на активстейт, толи где еще было написано почему так.

у Спольского в статье про алгоритм Шлемиэля

То что в питоне нет хранения по значению, и на каждый объект вызывается аллокатор — это проблемы питона.

это не проблемы питона, эта фича ;)

если ты захочешь реализовать такую фичу в сях ручками, «проблемы» начнутся уже у сей, верно? ;)

>у Спольского в статье про алгоритм Шлемиэля Не тут как раз это связано, что операция выделения памяти очень дорога. Поэтому если выделять память каждый раз это гораздо медленнее чем посмотреть сколько уже занимает массив, а потом выделить столько же. Вероятность того, что вы вставляете не последний элемент очень высока. А значит на следующих не надо будет выделять память пока вы опять не упретесь в конец.

Кроме того если память выделена, но не используется, то читаем про то как устроена виртуальная память. Про виртуальные страницы и т.п. Один процесс в теории имеет ООООЧЕНЬ много памяти. И он может запросить её всю, но использовать два байта. Вот и получится, что выделено вроде много, а используется не много.

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

Скорее всего жалобы на пакетный менеджер можно убрать просто взглянув какие массивы он там использует. Может напихать внутрь del для удаления неиспользуемых. Автор скорее всего даже не замечает этих тормозов. А жалобщики не могут ничего исправить (хотя было бы желание). Поэтому психологически чувствуют дискомфорт и сразу обвиняют всех в жлобстве и идиотизме.