From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-gdb@m.gmane-mx.org>
Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214])
 by sourceware.org (Postfix) with ESMTPS id B0A6F385801C
 for <gdb@sourceware.org>; Tue, 11 Jan 2022 18:05:03 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0A6F385801C
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <gdb-gdb@m.gmane-mx.org>) id 1n7LW2-000A7A-0t
 for gdb@sourceware.org; Tue, 11 Jan 2022 19:05:02 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: gdb@sourceware.org
From: Antoine Pitrou <antoine@python.org>
Subject: Tips for improving performance of Python pretty-printer?
Date: Tue, 11 Jan 2022 19:00:20 +0100
Message-ID: <20220111190020.34ccf144@fsol>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Newsreader: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,
 HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gdb@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb mailing list <gdb.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb>,
 <mailto:gdb-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb>,
 <mailto:gdb-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2022 18:05:05 -0000


Hello,

I'm implementing a bunch of pretty-printers (in Python) to improve the
debuggability of C++ types in Apache Arrow C++:
https://github.com/apache/arrow/pull/12092

However, I'm seeing performance issues where inspecting even relatively
simple information is quite slow as soon as I use the "natural" way, by
calling public C++ APIs (e.g. object methods) using
`gdb.parse_and_eval()`.

So for now I'm resorting to inspect private implementation details,
even for types I don't control such as `std::string` or `std::vector`.
As an example, I have the following helper code (simplified below for
clarity):

```
class SharedPtr:

    def __init__(self, val):
        self.val = val
        try:
            # libstdc++ internals
            self._ptr = val['_M_ptr']
        except gdb.error:
            # fallback for other C++ standard libraries
            self._ptr = gdb.parse_and_eval(
                f"{for_evaluation(val)}.get()")

    def get(self):
        return self._ptr


def for_evaluation(val):
    """
    Return a parsable form of gdb.Value `val`
    """
    ty = gdb.types.get_basic_type(val.type)
    if ty.code == gdb.TYPE_CODE_PTR:
        # It's already a pointer, can represent it directly
        return f"(({ty}) ({val}))"
    if val.address is None:
        raise ValueError(f"Cannot further evaluate rvalue: {val}")
    return f"(* ({ty}*) ({val.address}))"
```

This works fine but:

1) I need to maintain a generic fallback for non-GNU libstdc++
implementations of the C++ standard library
2) The generic fallback (obviously) suffers from the original
performance problem

Is it expected that `gdb.parse_and_eval` has such a poor performance?
(I didn't run any timings, but as a rough estimate I estimate that it
takes around 100 ms for a relatively simple expression)

Regards

Antoine.