<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Phyllis et al,<br>
<br>
While I have not tested the current state of the git repository, I
thought I might add a few comments about testing performance in
general from the perspective of a retired systems programmer. I am
a fan of Cinelerra-GG and use it for burning bluray disks so I
hope to be able to test the new code before long.<br>
<br>
I realize that the posts to which I am referring are not intended
as exhaustive, definitive test suites, but it can be useful to
know how the results can be affected. On most operating systems,
memory requested by an application is not returned to the system
wide free pool when the application releases it with a call to
free or delete. You can see this by running a memory intensive
application in one window and the gnome-system-monitor (or
equivalent) in another window. Unless there is a great deal of
demand for free memory by other applications, this memory will
remain assigned to the first application until that application is
closed. Therefore, each test should be run from a fresh invocation
of the test application. Unfortunately, this doesn't guarantee
that the file system cache is flushed.<br>
<br>
Any settings within a given application, eg cache or pre-roll,
will need to be measured in a controlled environment which means
rebooting the computer to clear the file system file cache.
Otherwise, any request for data that has been previously read may
be satisfied from the operating systems file cache regardless of
the settings in the application. That said, the effect of the file
system cache loading will be most or exclusively felt in short
tests that fit completely or mostly within the file system cache.
The tests should be run with as few other applications loaded as
possible to minimize CPU contention and disk access. If there is a
way to run the test from the command line, this will eliminate
additional video card specific rendering issues, by which I mean
presenting the images on the screen. I am not referring to using
GPU's used to render the video to the files on disk that will be
read during playback. Of course, if what you are trying to measure
is the onscreen presentation rate, then a command line test is not
appropriate.<br>
<br>
The terminal commands free and top can be used to see how much
memory is being allocated to caches. If you run these before and
after a test, you should see an increase in the memory allocated
to the file caches. <br>
<br>
You can use the command: cat /proc/meminfo to see how much memory
is being allocated to file system caches. Note: these values are
for an older laptop with only 8 GB of physical ram and an 8 GB
physical swap partition.<br>
<br>
cat /proc/meminfo<br>
<font face="monospace">MemTotal: 7802112 kB<br>
MemFree: 2199052 kB<br>
MemAvailable: 5405988 kB<br>
Buffers: 175436 kB<br>
<b>Cached: 3361856 kB</b><br>
SwapCached: 0 kB<br>
Active: 1470940 kB<br>
Inactive: 3556264 kB<br>
Active(anon): 4204 kB<br>
Inactive(anon): 1616348 kB<br>
<b>Active(file): 1466736 kB</b><b><br>
</b><b>Inactive(file): 1939916 kB<br>
<br>
</b>swapon<br>
NAME TYPE SIZE USED PRIO<br>
/dev/sda3 partition 7.9G 0B -2<br>
/dev/zram0 partition 7.4G 0B 100<br>
<br>
See the URL below for a description of the zram0 swap partition.<br>
<a class="moz-txt-link-freetext" href="https://www.kernel.org/doc/html/v5.3/admin-guide/blockdev/zram.html">https://www.kernel.org/doc/html/v5.3/admin-guide/blockdev/zram.html</a><br>
</font><br>
It goes without saying that any use of swap space will radically
degrade performance unless that swap space is on a solid state
drive and the swap partition is quite generous in size. Recent
versions of Fedora, ie 33 and newer, seem to favor a compressed
swap space and/or using memory compression, which can have a large
impact on memory intensive operations. My recommendation is to use
a dedicated, on disk (SSD) swap partition that is twice the size
of physical memory or larger depending on the memory requirements
of your application. I use the Fotoxx graphics application to make
very large panoramas and have frequently used up to 40 GB of swap
space on a system with 16 GB of physical ram. Cinerlerra is
nowhere near that memory hungry, but it is essential to avoid
running into situations where the kernel will have to evict code
pages or data from the cache.<b> </b>The output of the swapon
command indicates that the compressed zram0 block device has a
much higher priority than the physical disk based swap partition.
This can negatively impact file caching if your on disk swap
partition is fast and your memory is older, slower memory. It may
be worth trying to limit the size of your compressed swap device
as described in the URL above to see if that helps or hurts
performance. If the kernel is trying to compress already
compressed data, it may make more sense to force it to be written
to the SSD. This can only be determined by testing.<br>
<b><br>
</b>A very good tool to analyze memory usage during any given run
is heaptrack by Milan Wolf <br>
<a class="moz-txt-link-freetext" href="https://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux.html">https://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux.html</a>
<br>
<br>
It is available for most Linux distributions and works with
heaptrack_gui to display memory leaks and memory usage at each
point in an application run. If your distribution channel does not
have a current package for heaptrack, you can download the source
and compile it fairly easily.<br>
<br>
Richard Nolde<br>
<br>
</div>
<br>
</body>
</html>