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. 


Reply via email to