Hi Marc, Marc Chantreux wrote on Tue, Mar 03, 2020 at 10:05:41AM +0100: > Ingo Schwarze wrote:
>> :map K yw:E /tmp/vi.keyword.$$p!!xargs man <ENTER> >> >> i get: >> >> Error detected while processing function >> line 30: >> E132: Function call depth is higher than 'maxfuncdepth' > it's a bug in the :E command, i reported it there: > > https://github.com/vim/vim/issues/5723 > > thank you for spotting it. Heh. I'm a blind squirrel, and look at the nut i just found... >> Also, the patch that would be required is very small and straightforward. > indeed. you made me like reading C code. >> So, what do people think? Should i test the patch below in more >> depth and commit it? Or do people consider this bloat? > i'm very naive about performance things but: as you add a condition > in a loop that is used while reading the input, it will be a little > bit slower. > which means penality for everyone to avoid using a very simple pipe on > rare cases. so i finally think it's not worth ... col -b is an elegant > solution. I ran "mandoc /usr/share/man/man1/ksh.1" 100 times, 10 times. Before the change: 0m07.65s real 0m05.68s user 0m01.52s system 0m07.62s real 0m05.92s user 0m01.47s system 0m07.64s real 0m05.97s user 0m01.49s system 0m07.62s real 0m05.90s user 0m01.42s system 0m07.68s real 0m06.13s user 0m01.51s system 0m07.65s real 0m06.01s user 0m01.46s system 0m07.66s real 0m05.89s user 0m01.50s system 0m07.60s real 0m05.89s user 0m01.54s system 0m07.73s real 0m06.00s user 0m01.38s system 0m07.68s real 0m05.70s user 0m01.47s system 7.653 +- 0.037 seconds for 100 times ksh(1) 76.53ms +- 0.37ms for formatting ksh(1) After the change: 0m07.68s real 0m06.22s user 0m01.34s system 0m07.62s real 0m06.02s user 0m01.42s system 0m07.68s real 0m05.87s user 0m01.46s system 0m07.66s real 0m06.01s user 0m01.41s system 0m07.59s real 0m06.00s user 0m01.41s system 0m07.62s real 0m06.09s user 0m01.20s system 0m07.63s real 0m05.95s user 0m01.44s system 0m07.67s real 0m05.83s user 0m01.48s system 0m07.59s real 0m06.11s user 0m01.46s system 0m07.71s real 0m05.86s user 0m01.45s system 7.645 +- 0.041 seconds for 100 times ksh(1) 76.45ms +- 0.41ms for formatting ksh(1) So the slowdown is -8 +- 55 microseconds for formatting ksh(1) which is consistent with "no change" with a precision of about 7 permille. It would no doubt be possible to measure this with more precision, but i think knowing that there is no measurable performance change on a one-percent level is good enough. Also, i'm not surprised that one more "if" per output character isn't relevant compared to all the other stuff that needs to be done in the parsers and formatters. I still do performance testing before changing overall algorithmic order, but mere "if"s are almost never relevant. I even mostly stopped worrying about malloc(3) inside loops; at least in mandoc, i have rarely seen relevant effects of slowdown. Premature optimization is evil. Yours, Ingo
