"阿德烈 via GitGitGadget" [off-list ref] writes:
From: ZheNing Hu <redacted>
"alloc_state" may have similar effects with "mem_pool".
What "similar effects" do you have in mind? "mem_pool" may have
more than one "effects" to multiple things that are affected, but it
is unclear which effect that "mem_pool" exerts on what you are
referring to.
Using the new memory pool API may be more beneficial
to our memory management in the future.
Many things may or may not be "beneficial" in the future. We do not
build things on a vague "hunch".
Are you seeking performance (e.g. number of objects that can be
allocated per minute)? Are you seeking better memory locality
(e.g. related objects are likely to be stored in the same page,
reducing number of page faults)? Are you seeking reduced wasted
memory (e.g. custom allocator packs objects better than bog-standard
malloc(3))? Are you seeking functionality (e.g. you have this and
that specific codepaths and usecase where you wish to be able to
release all the objects instantiated for a particular repository,
without having to go through the list of all objects, and use of
mempool is one way to allow us do so)?
It is not even clear in your problem description what kind of
benefit you are seeking, let alone how much quantitative improvement
you are getting with this change.
To Junio:
Thanks for checking.forget my unprofessional
description.Macroscopically speaking,
both alloc_state and mem_pool are doing one thing:Apply for a
large block of memory in advance,and when needed a dynamically
allocated memory ,we call the interface function to apply for memory,
This can reduce the overhead of calling malloc multiple times.And the
mem-pool or alloc_state will Automatic Expand capacity.
So that ,my this patch may have something not considered,
mem_pool_init(o->blob_pool,0);
may be a wrong way to init this mem-pool
because:
void mem_pool_init(...)
...
if (initial_size > 0)
mem_pool_alloc_block(pool, initial_size, NULL);
the first time calloc malloc may decay to we first call "mem_pool_alloc_block",
I think this may not be great.
A little ashamed,I did not consider the optimization point of this
at the beginning,
Junio C Hamano [off-list ref] 于2021年2月2日周二 上午1:56写道：
"阿德烈 via GitGitGadget" [off-list ref] writes:
quoted
From: ZheNing Hu <redacted>
"alloc_state" may have similar effects with "mem_pool".
What "similar effects" do you have in mind? "mem_pool" may have
more than one "effects" to multiple things that are affected, but it
is unclear which effect that "mem_pool" exerts on what you are
referring to.
quoted
Using the new memory pool API may be more beneficial
to our memory management in the future.
Many things may or may not be "beneficial" in the future. We do not
build things on a vague "hunch".
Now,I make a rough comparison.
Situation : when we just use it to malloc little struct node
such as `object`,`blob` ,`tree`.
Are you seeking performance (e.g. number of objects that can be
allocated per minute)?
1. performance.
`mem_pool` api will allocate 2^20 byte everytime ,
`alloc_state` api will allocate 1024*nodesize byte and ALLOC_GROW everytime.
A repo like git may call malloc fewer times when using `mem_pool`,
while a small repo may not have this amount of objects. The number of
calling `malloc`
may be similar.
may be `mem_pool` win a little...
Are you seeking better memory locality
(e.g. related objects are likely to be stored in the same page,
reducing number of page faults)?
2. page faults .
I might think they are similar at first.But now,I start to understand
what you mean:`alloc_state` more like an object pool,so that we could
go through the list of all objects.Therefore, mem_pool is not conducive
to continuous access to all objects.Because There may be fragments
in the memory And this must be a cross-page operation.
so `alloc_state` win.
Are you seeking reduced wasted
memory (e.g. custom allocator packs objects better than bog-standard
malloc(3))?
3.Memory utilization.
`alloc_state`win.No doubt.
Are you seeking functionality (e.g. you have this and
that specific codepaths and usecase where you wish to be able to
release all the objects instantiated for a particular repository,
without having to go through the list of all objects, and use of
mempool is one way to allow us do so)?
4.functionality
yeah,As mentioned above.Object pool will be better.
`alloc_state`win.
5.
Indeed, the object pool `alloc_state` may be better than the
memory pool `mem_pool`.
But We can assume that the original author’s intention may be to
The five alloc_states are merged together.
Because the original author said: "migrate alloc_states to mem-pool"
Or another advantage of using the memory pool is that it can dynamically
allocate a variety of different objects, I now think the original author has
this intention.So my patch code also needs some modifications.But at the
same time, it may not be good to count them separately if multiple objects
are allocated using the memory pool at the same time.
so 'mem_pool' win a little.
It is not even clear in your problem description what kind of
benefit you are seeking, let alone how much quantitative improvement
you are getting with this change.
I don't know how to quantify them temporarily.
I may need the opinions of you and the original author before I can move on.
Thanks.