blob: 8164b04de10b9d6c201201ffa620b7ff63d4650f (
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
|
Used pools:
-------------------------------+-----------------------------+-----------------------------
head / name | size | define
-------------------------------+-----------------------------+-----------------------------
pool_head_ buffer | global.tune.bufsize = 16384 | USE_POOL_BUFFER
pool_head_ trash | 32 + 16384 | USE_TRASH_CHUNK
-------------------------------+-----------------------------+-----------------------------
pool_head_ ot_scope_span | 96 | USE_POOL_OT_SCOPE_SPAN
pool_head_ ot_scope_context | 64 | USE_POOL_OT_SCOPE_CONTEXT
pool_head_ ot_runtime_context | 128 | USE_POOL_OT_RUNTIME_CONTEXT
pool_head_ ot_span_context | 96 | USE_POOL_OT_SPAN_CONTEXT
-------------------------------+-----------------------------+-----------------------------
By defining individual definitions in file include/config.h, it is possible to
switch individual pools on / off. If a particular pool is not used, memory is
used in a 'normal' way instead, using malloc()/free() functions.
This is made only from the aspect of debugging the program, i.e. comparing the
speed of operation using different methods of working with memory.
In general, it would be better to use memory pools, due to less fragmentation
of memory space after long operation of the program. The speed of operation
is similar to when using standard allocation functions (when testing it was
shown that pool use was fast by about 1%).
|
