Otto Moerbeek <o...@drijf.net> wrote: > On Wed, Jun 06, 2018 at 11:25:43AM +0100, Stuart Henderson wrote: > > > On 2018/06/06 09:57, Stuart Henderson wrote: > > > I've been finding vim with my standard settings really slow on OpenBSD. > > > It's been bugging me for a while, but it just took about 1.2s to open > > > and display a 20k patch, which was bad enough to make me dig into it > > > again. > > > > > > I've looked at malloc options in the past and noticed that 'j' helps > > > but this has caught enough bugs in the past that I'd really prefer > > > not to use it. Looking again today I noticed that increasing the free > > > page cache size by setting >> helps hugely, taking this down to 0.4s. > > > > > > Would there be any sense in having a way for a program to request some > > > different default malloc option, or at least different default cache > > > size, while still allowing user settings to override it, so this can > > > work better by default without changing behaviour for other programs? > > > > > > Or perhaps it should just be considered a bug/problem in vim, > > > > > > These settings in .vimrc make it quite noticeable > > > > > > syn > > > > ugh sorry, 'syn on' or 'syntax enable'. Thanks tb@ > > > > > set foldmethod=syntax > > > set foldlevelstart=1 > > > > > > I normally have more, in particular to fix the horrible the default colour > > > scheme ;) but minimal is better as a test case .. the file I was opening > > > today: > > > https://github.com/openbsd/src/commit/f695adb710e886406ee58a1fe647719c07d844d7.patch > > > > > vim is causing tons (more than 2 million) of mmap and munmap calls > with the default cache size for this test case. If you enlarge the > cache that drops to about 50k. Note that that means that vim generates > at least that many malloc/realloc/free calls (not all calls of these > cause mmap or munmap syscalls to be done). That is quite a lot for > displaying some colors, to put it mildly. > > In general, the aggressive munmapping of malloc is a good thing. It > cacthes lots of use-after-free bugs. So I'm not a fan of increasing > the default cache size.
I suggest someone tell vim upstream; perhaps even send them a ktrace/kdump to show what their program is doing. or the equiv of ltrace.
