Bug 27979

Summary:	Performance regression of ~10% in conditional breakpoint testcase
Product:	gdb	Reporter:	Magne Hov <mhov>
Component:	gdb	Assignee:	Not yet assigned to anyone <unassigned>
Status:	UNCONFIRMED ---
Severity:	normal	CC:	simark, ssbssa
Priority:	P2
Version:	HEAD
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:
Attachments:	reproducer program #gdb chatlog

Description Magne Hov 2021-06-14 12:44:46 UTC

Created attachment 13491 [details]
reproducer program

There seems to be a performance regression from 9.2 to 10.2 that is observable in the time to run the following command on the attached reproducer program. This has been used to benchmark the performance of conditional breakpoints.

  $ gcc --version
    gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
  $ gcc -g repro.c
  $ ./gdb --batch --ex "b foo if bar==0x7ffffff" --ex "run" --args ./a.out

Also attached is a log from the libera.chat #gdb channel where this regression was discussed.

As can be seen in the attached chat log, bisection by Simon suggests that this commit is to blame: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1009d92fc621bc4d017029b90a5bfab16e17fde5

I'm not currently in a position to delve deeper into this, so I'm posting here in case anyone wants to pick it up.

Comment 1 Magne Hov 2021-06-14 12:45:35 UTC

Created attachment 13492 [details]
#gdb chatlog

Attached chatlog

Comment 2 Simon Marchi 2021-06-14 12:58:34 UTC

Things to investigate:

 - We do a lot of work finding tailcalls even though no tailcalls are involved the test case.  Is there a way we can do less work in this case?
 - On the fast path, while looking for tailcalls, a NO_ENTRY_VALUE_ERROR exception is thrown.  It's probably not good to rely on exceptions being thrown in the normal path of the program, maybe try to change that with functions returning nullptr if they don't find anything.