I've gone to some length to ensure that tracker doesn't use too much memory, and is still fast enough. Specifically, I'm storing note values instead of actual pitches (see The Protracker format).
Some modules don't use all the patterns stored within the file, and in fact, only junk is stored in the unused patterns. For that reason, tracker now analyses a module to remove unused patterns and unused samples. This ensures that note values will be correct, reduces memory consumption slightly, and junks binary files in a quick way.
Here is a rundown of tracker memory consumption, for a
typical machine where short
values
occupy 2 bytes and long
values 4 bytes:
In the end, memory consumption is very close to the actual length of the file on disk (sometimes less). As a benefit, the file is scatter-loaded into memory. Tracker works well even when the memory is somewhat fragmented.
Recently, I've added a memory allocation logging tool to tracker
(`mung.c
'). To use it, you just have to recompile tracker with
`-DMUNG
' and add `mung$O
' to the list of object files.
Tracker will then log all of its memory activity to `logfile
'.
It is then trivial to write, for instance, a perl script that will analyze
this file and retrieve interesting statistics about tracker.
I was able to trace several minor memory leaks thanks to this tool, and discover that tracker uses very little memory of its own. In fact, tracker uses most of its memory for audio samples (some 500K out of 660K) on a real life example.
This shows quite clearly why it might be useful to load samples on need instead of having them in memory all the time.