summaryrefslogtreecommitdiff
path: root/Development/MemoryUsage.mdwn
blob: b4531cb109dc6c66f25c6d2a043988c142675a6d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Misc memory-related optimization ideas. See also [[http://elinux.org/Decrease_X.org_XFree86_server_footprint|http://elinux.org/Decrease_X.org_XFree86_server_footprint]]  


# Server-side optimizations


## Modularizing core protocol support


[[!format txt """
00:00 < dottedmag> I had a look at Xfbdev binary - some kind of lazy loading for FbArc and FbPolyline 
                   etc may significantly reduce the main binary size. Given nobody runs really old 
                   applications on embedded stuff remnants of old stuff won't use memory and OTOH it 
                   is still available if needed.
00:01 < dottedmag> Same for e.g. core text handling
00:02 < vignatti> interesting
00:02 < dottedmag> Should be easy to implement using the technique similar to the PLT/GOT tables, 
                   given all requests are called through lookup table anyway.
00:02 < daniels> yeah, that would be neat, though note that if you never reference a page, it's not 
                 going to get loaded
00:03 < daniels> (note also that moving stuff into shared libraries is counterproductive unless your 
                 shared library is exactly aligned to page size)
"""]]

# Client-side optimizations


## libxcb ("many DSO" problem)


[[!format txt """
00:08 < dottedmag> daniels: I have been hit by this already: tons of xcb-util and libxcb libraries 
                   use 300kB per app just for relocation tables.
00:09 < dottedmag> *per process
00:10 < ajax> the xcb libs should be one actual library and a bunch of ELF fitlers
00:11 < ajax> filters, even.
00:11 < ajax> first person to implement that wins a bottle of their whiskey of choice
00:11 < dottedmag> ajax: elf filters? wanna know/read!
00:11 < ajax> man ld, y0
00:12 < ajax> there's two kinds, but the one i mean here is where the DSO is nothing but a list of 
              symbols and a reference to a library to source them from.
00:13 < ajax> which means you could have a libxcb-everything.so, and libxcb-randr.so would just 
              export the randr symbols from libxcb-everything.so
00:13 < ajax> so you only get the namespaces you want
00:13 < dottedmag> ajax: how much memory will the filter take?
00:13 < dottedmag> loaded
00:13 < ajax> but it only loads the DSO once
00:13 < ajax> dottedmag: not a lot?  there's not much to it beyond the symbol list, i'd be surprised 
              if it was more than a page after loading.
00:14 < dottedmag> well, right. There aren't any C++ symbols, so the stuff should be pretty short.
00:14 < ajax> should almost certainly be less memory than the 3+ pages per DSO for each xcb extension 
              lib
"""]]