From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EXHkAU3Z3WGzVAAAWB0awg (envelope-from ) for ; Tue, 11 Jan 2022 14:23:57 -0500 Received: by simark.ca (Postfix, from userid 112) id E74331F34E; Tue, 11 Jan 2022 14:23:56 -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 1FC1C1EAA4 for ; Tue, 11 Jan 2022 14:23:56 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8A71238B3432 for ; Tue, 11 Jan 2022 19:23:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A71238B3432 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1641929035; bh=pvcVxrLh5lNA5XD5FbQwA0kfjFrOc6cCbou15Yek6jM=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=iZOcRaLcjKPmr0+9ZJ+rGvggg/iJFcmRJpEyZJsSH7tCftm2GrVFq6l8fUaoOp2TO j7eE+Iwu1yRzZvQXe2Mc8gQP3wr5IX52GDpIeXXZutdyM7ZZEJCU9AzrOwXB+o0+AL YUnCvfJHj1CbTHMtUS2gRCgb3vlBGNs/oD7E1oIU= Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by sourceware.org (Postfix) with ESMTPS id 51E9A38B3434 for ; Tue, 11 Jan 2022 19:22:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 51E9A38B3434 Received: by mail-yb1-xb32.google.com with SMTP id h14so32909034ybe.12 for ; Tue, 11 Jan 2022 11:22:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dd3Pcn93DvpY1+O0xm1tyeBYpmVQUlbVVsHcn+DjFw0=; b=Z8CYY2bTV9efc9nHM4jbFOIU+7+4Zxk3KTFmxEp9pFudujaVZuF12BOvYDVG1UjIri mky1C1535z7RvPXZh9gTaM3tyZd2nUfEXIuHUBpAQrIJODwZ/HYybpNmg1qBWqGRWBjz Kxk9d6XnteFHBZC2zvxMC/aybylEMQ7OnAHfOzyeGzHSMtLQChV5anIknsFpf5a/Pkxb I77Lz1/Lmh0TkQKoKVJJSfIn6T8LGqCjuBQRW+zMTuUHmEmKTwSCCRV0iWkLM3Ei4+KH fJnQxIAomtSwjsn/Lf6N1EjyJkof3S4edbqZwUA+ZG+PrJH0ZWDJV81aariAPPlDgHYe GPxQ== X-Gm-Message-State: AOAM5303gI/5vBf1cZBA+blYZRMjEa8T34vwo9tjf8NF7lTO5uYfmclY V6D11J/u9GXcHLH5mmOjfFLF9lQ8Axf9hw1prfdc2KRw X-Google-Smtp-Source: ABdhPJzz4+UjeFGRH7Au6LwuJhjG3GMddlthPdv94wjVMLPVFNVAD6JIIABJEs5Cnah2X4XzDlnnoIZZeyMH+iaVP4M= X-Received: by 2002:a25:388a:: with SMTP id f132mr8437471yba.102.1641928978796; Tue, 11 Jan 2022 11:22:58 -0800 (PST) MIME-Version: 1.0 References: <20220111190020.34ccf144@fsol> In-Reply-To: <20220111190020.34ccf144@fsol> Date: Tue, 11 Jan 2022 11:22:47 -0800 Message-ID: Subject: Re: Tips for improving performance of Python pretty-printer? To: Antoine Pitrou Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: David Blaikie via Gdb Reply-To: David Blaikie Cc: gdb Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" One side note: Generally pretty printers should not call into the code under test - doing so means the pretty printer can't be used when debugging a core dump, and risks not being usable when the process is corrupted in some ways, or risks creating corruption/disturbing a reproduction by executing code in the test program. On Tue, Jan 11, 2022 at 10:05 AM Antoine Pitrou via Gdb wrote: > > 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. > > >