![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to memory-usage.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [HATARI the Atari ST Emulator] / hatari / doc|
Return to memory-usage.txt CVS log | Up to [HATARI the Atari ST Emulator] / hatari / doc |
1.1 root 1:
2: HATARI MEMORY USAGE
3:
4: Here are some stats on Hatari 0.81 memory usage (on Linux) and what
5: could be done to decrease it for embedded devices.
6:
7:
8: First the binary size from "size ./hatari":
9: text data bss dec
10: 1382406 10712 18255264 19648382
11:
12: I.e. the binary size is 1.3MB, it has 10KB of pre-defined arrays and
13: 18MB of non-initialized fixed size arrays. The names of the arrays
14: are listed at the bottom, but STRam is the one taking 16MB.
15:
16: Happily Hatari doesn't dirty (zero) all of STRam, just first 4MB
17: (accessible as ST ram) and 2MB at the top (used as IO-memory,
18: TOS and cartridge memory). In next Hatari version Hatari will
19: zero only part of the ST ram that user has configured
20: (e.g. 0.5MB instead of 4MB -> 3.5MB private memory save).
21:
22:
23: When I profiled Hatari with Valgrind (valgrind.kde.org) Massif plugin,
24: it tells that Hatari malloc()s about 3MB of memory. The allocations
25: and how to make them smaller for embedded devices (no generic way
26: unfortunately) are:
27:
28: * In includes/vdi.h set MAX_VDI_WIDTH and MAX_VDI_HEIGHT from 1024 and
29: 768 to 640 and 400 respectively. This decrease memory usage from 1.5MB
30: to 0.5MB (btw. for page flipping Allocation 2*2 framebuffers).
31: - Change list of VDI modes in Hatari dialog accordingly
32:
33: * Do not load bigfont in gui-sdl/sdlgui.c, especially if the device
34: screen is smaller than VGA. Both fonts together take about 1/3 MB.
35:
36: * Change uncompressed file read to use mmap() instead, currently
37: memory is allocated for the whole disk image before reading it.
38: - With normal DD floppy image Hatari would use that amount which
39: might be acceptable, but with e.g. 2MB disk needed for running
40: Wolf3D v0.8, mmap() sounds much better
41: - For compressed disk images memory needs to be allocated for
42: uncompressed image data, i.e. there we cannot save memory.
43:
44: * Check whether the m86k instruction table could be made smaller:
45: #include "uae-cpu/readcpu.h"
46: printf("%d -> %d\n", sizeof(struct instr), sizeof(struct instr) * 65536);
47: On x86 it's slightly over 1MB.
48:
49: You can also Massif Hatari yourself, its allocation calltrees
50: are very short, so it's easy to find these from the produced
51: PostScript graph and txt/html calltree listing.
52:
53:
54: From /proc/sysvipc/shm one can see how much shared memory Hatari/libSDL
55: has allocated and that it shares it with the X server:
56: - >100KB in lowrez
57: - ~200KB in lowrez with borders
58: - ~500KB in monochrome or zoomed lowrez
59: - >800KB in zoomed lowrez with borders
60: I don't think these could be made smaller from the code. Besides
61: user can just use a the smaller Hatari screen mode.
62:
63: According to Xrestop, Hatari doesn't keep any Pixmap resources
64: at the X server side.
65:
66:
67: Finally when looking at the Hatari process with "pmap", you can
68: see that the binaries Hatari links don't use so much private
69: (writable) memory:
70: map <Hatari PID>|grep /|grep w
71:
72: Rest of the 30MB Hatari VMSIZE you see in "top" (about 10MB), goes to
73: shared library code (their .text sections with "r-x" rights) Hatari
74: links. That is memory mapped read-only / read in on-demand / pagable
75: back to disk so it's not so much of a problem.
76:
77:
78: Unmodified Hatari runs on (Linux) systems having about 20MB of free
79: memory (e.g. according to /proc/meminfo free+buffers+cached fields).
80: Using low-rez without borders nor zooming, setting emulated ST memory
81: amount to <=1MB, limiting the VDI screen size and removing bigfont
82: (discussed with Massif findings above) should enable running Hatari
83: well on a system with only 10MB free memory, if it's otherwise fast
84: enough.
85:
86:
87: - Eero Tamminen
88:
89: To see the objects in the binary BSS section, get the datadump script
90: from here:
91: http://live.gnome.org/MemoryReduction_2fTools
92:
93: Compile Hatari without stripping, and use:
94: datadump.py -n -s .bss ./hatari
95:
96: As a result you see these array variables (larger ones):
97: 16777216 STRam hatari
98: 321536 CyclePalettes hatari
99: 262144 mem_banks hatari
100: 262144 cpufunctbl hatari
101: 131072 pInterceptWriteTable hatari
102: 131072 pInterceptReadTable hatari
103: 69632 InternalDTAs hatari
104: 65536 EnvelopeShapeValues hatari
105: 53588 DialogParams hatari
106: 53588 ConfigureParams hatari
107: 19976 FrameBuffers hatari
108: 16384 ST2RGB hatari
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.