STINNER Victor added the comment:

Hi,

Serhiy Storchaka: "The performance of print() is not critical. It usually 
involves slow formatting and IO."

Oh, please, I want a print() using METH_FASTCALL! Not for the performance, but 
just to help me in my development!

To identify code not using FASTCALL yet, I'm putting a breakpoint on 
_PyStack_AsTuple() and _PyStack_AsDict(). It's common to stop on print() when 
testing the performance benchmark suite.

FYI currnently, I'm adding the following Python code to python-gdb.py:
---
class MyBreakpoint (gdb.Breakpoint):
    def stop(self):
        # frame of the caller
        frame = gdb.selected_frame()
        frame = frame.older()

        name = frame.name()
        if name == '_PyCFunction_FastCallKeywords':
            pass
        else:
            # callable->ob_type
            obj = frame.read_var('callable')
            obj = obj.referenced_value()['ob_type']

            obj2 = gdb.lookup_global_symbol('PyType_Type').value()

            if obj == obj2.address:
                return False

            print("don't skip", obj, obj2.address)

        gdb.execute("up")
        return True


MyBreakpoint("_PyStack_AsTuple")
MyBreakpoint("_PyStack_AsDict")
---

These macros make gdb 40x slower :-/

The code is used to skip type_call(): this function is known to not use 
FASTCALL yet. I plan to add tp_fastnew and tp_fastinit to optimize type_call(), 
but it's already hard enough to implement tp_fastcall, so I will do it later.

> _PyArg_ParseStackAndKeywords() is a part of unstable, fast-evolved API. I 
> would beware of using it in common code.

Ah. I have a different opinion on that. Since _PyArg_ParseStackAndKeywords() 
and print() are part of the Python core, we have free to use private 
fast-moving APIs.

By the way, _PyArg_ParseStackAndKeywords() already uses the new efficient 
_PyArg_Parser object. Do you plan other enhancements?


INADA Naoki: "I see.  AC should support this."

Right, but IMHO it can be done later.

I tried to contribute to AC but the code is super complex. I understood that AC 
is not complex, but Python is complex :-D AC is full of corner cases. It's a 
very long list of special cases :-)

----------
status: pending -> open

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29296>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to