From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dblaikie@gmail.com>
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 <gdb@sourceware.org>; 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 <gdb@sourceware.org>; 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>
From: David Blaikie <dblaikie@gmail.com>
Date: Tue, 11 Jan 2022 11:22:47 -0800
Message-ID: <CAENS6EvBXVSMc1HCtpiSN9qAUgfT2zDsX=LD8G0uAmf91gzFnQ@mail.gmail.com>
Subject: Re: Tips for improving performance of Python pretty-printer?
To: Antoine Pitrou <antoine@python.org>
Cc: gdb <gdb@sourceware.org>
X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE,
 RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
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 <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 19:23:01 -0000

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 <gdb@sourceware.org>
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.
>
>
>