From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SD8dMOrG3WFlUQAAWB0awg (envelope-from ) for ; Tue, 11 Jan 2022 13:05:30 -0500 Received: by simark.ca (Postfix, from userid 112) id B48AB1F34E; Tue, 11 Jan 2022 13:05:30 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2C2661EAA4 for ; Tue, 11 Jan 2022 13:05:30 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 355DE38A9427 for ; Tue, 11 Jan 2022 18:05:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 355DE38A9427 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1641924329; bh=JdF9iyod2hI4fyYN5VtRk+py2Id2WYoY/AJmfY303Y0=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=gEfib4rz7DEI6QPbfxVRC/vmScqEv4lsI9ou5WMSm2QtE0TCSk4LRD9GfSn0meHuU /F0Vkk5fMRhjLklpV+CetZ5JihrK25njfvsQvEUibz+1V2WQ1odTxMfwcNWNpV14pJ GTUlnh60Z1Sn+aNlPoSwSizZiXXTZy/sKT2e04Hw= Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id B0A6F385801C for ; 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 ) 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 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-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Antoine Pitrou via Gdb Reply-To: Antoine Pitrou Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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.