This Time Self-Hosted
dark mode light mode Search

Massif Attack

I know it’s a bad pun for a title, but I’m Mr. Bad Pun, so i can allow myself to it 😉

Today, I needed a day of relax, and also some time for housekeeping tasks, like cleaning up, helping my mother, pack out the stuff I don’t need here anymore and so on.

But I’m one of the people who can’t simply relax by watching some movie on the screen, and my relax for today is valgrinding xine, using the massif tool trying to find leaks and memory wastes.

The first thing I found, it’s that picoxine used to initialise also the video output driver, resulting in 10 megabytes of memory waste every run (picoxine only outputs audio), and that is now solved at least locally; I’ve sent a patch to the author, so he can fix it for everyone on next release.

The tricky part was to provide the list of functions that are just malloc() aliases or similar functions. What I currently have on my .valgrindrc file is:

--alloc-fn=strdup

--alloc-fn=xine_xmalloc
--alloc-fn=xine_xmalloc_aligned
--alloc-fn=_x_fifo_buffer_new
--alloc-fn=_x_new_scratch_buffer

--alloc-fn=av_malloc
--alloc-fn=av_mallocz
--alloc-fn=av_mallocz_static

--alloc-fn=ft_mem_qalloc

that covers xine’s alloc function, FFmpeg alloc function, a FreeType function I found casually, and strdup() function that seems to be used quite a bit 😉 The x functions are internal xine functions that allocates buffers, although they aren’t technically speaking malloc() aliases, I’d rather have them ignored, and their callers identified instead.

Now, I’m trying to find if there are some leaks here and there, and trying to optimise it a bit. To be precise, in this moment I’m working on making sure than log_buffers are never exported outside libxine, and allocated only when really needed (in most of the cases, you don’t have to allocate them, because of verbosity disabled, for instance), that should save about 500KiB of memory space.

<!–
Before the change:

after the change:

You can see that the space is now distributed in a different way, and that the memory before occupied by xine_new mostly moved to xine_log; this is due to the log buffers being allocated only when they get used, which isn’t that bad, but not good enough to me either.

–>

Update (2017-04-30): This used to include a number of graphs, but unfortunately I don’t have any more reference for them, so for now they are gone.

On this graph you can see a bigger difference in allocation: this is with dynamic buffers for the log. This means that not only the log_buffers entries are created only when used, but also the line entries are created only when really needed, avoiding allocating 3*150*1024 immediately at startup.

Now, for the people interested, the way to convert the massif output (PostScript files) to PNG to blog publishing, is pstoimg -crop a -flip r90, that creates the png files you can see linked here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.