misc/54213: Significant performance degradation of whatis(1) after src/usr.sbin/makemandb/whatis.c,-r1.6

[leot%NetBSD.org@localhost]

>Number:         54213
>Category:       misc
>Synopsis:       Significant performance degradation of whatis(1) after src/usr.sbin/makemandb/whatis.c,-r1.6
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri May 17 20:20:00 +0000 2019
>Originator:     Leonardo Taccari
>Release:        NetBSD 8.99.37
>Organization:
Università Politecnica delle Marche
>Environment:
	
	
System: NetBSD arm64 8.99.37 NetBSD 8.99.37 (GENERIC64) #0: Fri Apr 26 18:04:06 CEST 2019 leot@abacus:/tmp/obj/sys/arch/evbarm/compile/GENERIC64 evbarm
Architecture: aarch64
Machine: evbarm
>Description:
	After revision 1.6 of whatis.c:

	----------------------------
	revision 1.6
	date: 2017-04-23 18:56:49 +0200;  author: abhinav;  state: Exp;  lines: +10 -4;  commitid: tfkpTFPDR89xbGOz;
	Teach whatis(1) to handle MLINKS

	Similar to apropos(1), whatis did not utilise the mandb_links table till now.
	Therefore, if it was asked about one of the links to a man page, it would
	error out. This change teaches whatis(1) to look up both the FTS table
	as well as the links table, thus ensuring that it is able to answer queries
	about MLINKS as well.

	Comparision between outputs before this change and after this change:

	#Before change
	$ whatis realloc
	realloc: not found

	#after change
	$ ./whatis realloc
	realloc(3) - general memory allocation operations
	realloc(3) - general purpose memory allocation functions
	realloc(9) - general-purpose kernel memory allocator
	----------------------------

	whatis(1) performance degradated significantly.
>How-To-Repeat:
	(At the time of writing this the latest whatis.c revision is -r1.7.)

	% cd src/usr.sbin/makemandb
	% make whatis
	[...]
	% mv whatis whatis-1.7
	% cvs up -r1.5 -p whatis.c > whatis.c
	% make whatis
	% mv whatis whatis-1.5

	And then running whatis(1) 10 times against a query that produces no
	results (`foo'): 

	% time sh -c 'for i in $(seq 10); do { ./whatis-1.5 foo 2>/dev/null; } done'
	0.048u 0.305s 0:00.35 97.1%     45+1208k 0+0io 120pf+0w

	% time sh -c 'for i in $(seq 10); do { ./whatis-1.7 foo 2>/dev/null; } done'
	29.509u 2.826s 0:32.45 99.5%    0+16k 0+0io 120pf+0w

	(The times are the one of a Pinebook with a `/' on a uSD but the
	slowdowns can be recognized also on faster machines.) 
>Fix:
	No idea, sorry.

	If the SQL query could not be optimized it should be probably
	worth to add a way to disable MLINKS handling.

>Unformatted: