[pypy-dev] a possible leak in the object namespace...

[Alex A. Naanou]

On Tue, Nov 30, 2010 at 20:33, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Hi Alex,
>
> On 11/29/2010 09:02 PM, Alex A. Naanou wrote:
>>
>> On Mon, Nov 29, 2010 at 21:46, Carl Friedrich Bolz<cfbolz at gmx.de>  wrote:
>
> [snip]
>>>
>>>  a) lots of attributes, which we expect to be rare
>>>  b) access them with setattr, which is a lot slower than a fixed
>>> attribute
>>>  c) access a different attribute every loop iteration, which means the
>>> compiler has to produce one bit of code for every attribute
>>
>> This is intentional (all three points), I did not want the jit to
>> factor out the loop -- I wanted to time the initial attribute
>> creation...
>
> Yes, I fear initial attribute creation is never going to be very efficient.
>
> [snip]
>>
>> But quadratic behaviour + a three orders of magnitude increase in time
>> it takes to create an attr is scarry... but you are right, how often
>> does that usecase happen? :)
>
> I improved some things so that setattr/getattr is a bit faster. Should now
> only be one or two orders of magnitude :-). If you run it tomorrow with the
> nightly build from tonight, you should see an improvement.

That's good news!
It is not uncommon, at least in my work, to write generic code that
does not know of attribute names it uses, thus getattr/setattr
functions are unavoidable.


> The quadraticness is not easily fixable without giving up all optimizations
> with instances of more than X (maybe 1000?) attributes. Again, I don't think
> this is common. And I don't want to chose an X.

I'd even argue that most of the cases were the number of attributes
exceeds a certain "sane" N would and should be better implemented via
a container...
(in spite of the how I wrote the code in my first mail ;) )

I've been planning of moving most of my commercial projects to PyPy as
soon as it is stable enough -- I'm tired of fighting the CPython
implementation for most of the time -- we will see how it goes... too
bad some of the code will be PyPy specific due to the way CPython
works.


Thanks!


>
> Cheers,
>
> Carl Friedrich
>



-- 
Alex.