Maciej Fijalkowski, 23.08.2012 11:17: > On Thu, Aug 23, 2012 at 11:11 AM, Stefan Behnel <stefan...@behnel.de> wrote: >> Maciej Fijalkowski, 05.07.2012 14:50: >>> On Thu, Jul 5, 2012 at 2:35 PM, Stefan Behnel wrote: >>>> Maciej Fijalkowski, 05.07.2012 11:01: >>>>> On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote: >>>>>> 2012/7/5 Stefan Behnel >>>>>>> Back to that question then: >>>>>>> >>>>>>>> Is there a way to get readable debugging symbols in a translated PyPy >>>>>>>> that would tell me what is being executed? >>>>>> >>>>>> I fear that pypy standard distribution calls "strip" on the resulting >>>>>> binary. >>>>>> You could translate pypy yourself, I'm quite sure it contains debug info >>>>>> already and it's quite easy to call "make debug" anyway. >>>>> >>>>> Default build (not the distribution or nightly, you have to trasnlate >>>>> yourself), contains debug info. >>>> >>>> Ah, yes. Given a suitably large machine and enough time to do other stuff, >>>> that did the trick for me. Here's the result: >>>> >>>> http://cython.org/callgrind-pypy-nbody.png >>>> >>>> As you can see, make_ref() and Py_DecRef() combined account for almost 80% >>>> of the runtime. So the expected gain from optimising the PyObject handling >>>> is *huge*. >>>> >>>> The first thing that pops up from the graph is the different calls through >>>> generic_cpy_call(). That looks way to generic for something as performance >>>> critical as Py_DecRef(). >>>> >>>> Also, what's that recursive "stackwalk()" thing doing? >>> >>> Haha :) >>> >>> This is related to garbage collection - it scans the stack for GC pointers >>> to save them I think. We might think that it's a bit too much to do it for >>> every single call there. >> >> So, what's the plan of doing something about it? > > I took a look at it and it seems it's not what I thought it is. > > It's just an intermediate call that saves stack roots and then calls > the actual cpyext. I don't think the call itself is harmful, it just > happens to be on the callstack (always)
Ah, ok - good to know. Then I think our next best bet is to cache the PyObject structs for PyPy objects using a weak-key dict. That will fix two problems at the same time: 1) prune excessive create-decref-dealloc cycles 2) keep the PyObject pointer valid as long as the PyPy object is alive, thus preventing crashes for code that expects an object reference in a list (for example) to be enough to keep the C object representation alive. Stefan _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
