Many getpid calls wasting CPU resources

[exrok]

With both fish 3.0 and fish 2.7.1 since Glibc disabled the getpid cache, fish shell seems to call getpid a lot. I have observed this issue on Arch linux for a couple of months. Using, the default configuration a strace -c fish followed by a C-d to terminate the shell gives,

time	seconds	usecs/call	calls	errors	syscall
38.95	0.003541	1	2216		getpid
14.81	0.001346	1	715	13	ioctl
6.59	0.000599	1	353		getpgrp
5.54	0.000504	1	284		fcntl
5.36	0.000487	2	226	79	read

The effect is worse with my current personal configuration, it has even more calls seen below is the top strace results run on fish 3.0.

time	seconds	usecs/call	calls	errors	syscall
49.25	0.013099	1	8442		getpid
15.75	0.004189	1	2616	255	ioctl

I think many of these calls are probably unnecessary. Further, the shell continues to call a large amount of getpid calls during use as well not just startup.

[faho]

This is actually mostly down to one single assert.

parser_t &parser_t::principal_parser() {
    ASSERT_IS_NOT_FORKED_CHILD();
    ASSERT_IS_MAIN_THREAD();
    return s_principal_parser;
}

It turns out this is hammered.

Since it's just an assert, let's just remove it.

That reduces my tally from 789 to 15, for a simple fish -ic exit.

Quite surprisingly, it also seems to reduce the time taken for

for i in (seq 10000); test 1 = 1; end

by ~40%.

[faho]

Fixed by a7998c4.

[zanchey]

Is a7998c4 safe to go into 3.0.1? I presume ASSERT_IS_NOT_FORKED_CHILD was being called for a reason... I see @mqudsi has optimised this assert significantly but not restored it in this place.

[ridiculousfish]

Yes it's safe. The assertion is just to catch mistakes, it has no functional purpose.

[floam]

Has anybody compared performance in fish with and without NDEBUG (disables asserts for release builds)?

[faho]

@floam: Our assert isn't from assert.h, and it does not respect NDEBUG.

See src/common.h.

[ridiculousfish]

Picked into 3.0.1 as 171ae99