realloc testing

[fir]

i run such code

union rchunk
{
chunk c;
};


rchunk AllocChunk(rchunk x, int size)
{
x.c.beg = (char*) realloc(x.c.beg, size );
x.c.end = x.c.beg + size -1;
return x;
}



rchunk dipa;

void rchunk_test()
{


for(int i=1; i<100000; i++)
{
dipa = AllocChunk(dipa, i);
printf("\n %i %p", ChunkLength(dipa.c), dipa.c.beg);
}

for(int i=100000; i>0; i--)
{
dipa = AllocChunk(dipa, i);
printf("\n %i %p", ChunkLength(dipa.c), dipa.c.beg);
}
}

it essentially does reallocks on some pointer: from 1 uo to 100 000 and then from 100 000 down to 1


i rarely use reallocks (though more than mallocks) and i dont tested it before

i knew that if i call realloc probably not all calls will 'produce' new pointer, however i see probably i was wrong becouse i assumed it will produce new pointer quite often and i even was doing my optimistation of its calls handled by my code, now it seem it was not needed becouse what this test show

1 003e2488
2 003e2488
3 003e2488
4 003e2488
5 003e2488
6 003e2488
7 003e2488
8 003e2488
9 003e24b0
10 003e24b0
11 003e24b0
12 003e24b0
...
958 003e24b0
959 003e24b0
960 003e24b0
961 003e4958
962 003e4958
963 003e4958
964 003e4958
....
46757 003e4958
46758 003e4958
46759 003e4958
46760 003e4958
46761 009b0048
46762 009b0048
46763 009b0048
46764 009b0048
...
99998 009b0048
99999 009b0048
100000 009b0048
99999 009b0048
99998 009b0048
...
6 009b0048
5 009b0048
4 009b0048
3 009b0048
2 009b0048
1 009b0048

some comments on that? (i use mingw so i think this is msvcrtdll.realloc implementation )

i wonder if i will put more other reallocks
on couple of other resizable chunks it will behave the same or it is independant

(it seems that this implementation dont favor optimisation of memory usage too much,
and avor lightnes of reallocking, (at least maybe for smaller chunks and if system ram pool is reletively big - probably those algorithms take amount of system or free system ram into account) - its maybe good news to me as i dont need this kind of code
myself (what i was trying to do as i said on my side and it was unhandy and seem redundant/nonsensical)

[fir]

this rises also one side question:
is reallocking to zero eqivalent of free?
(logically it probably should be like that
(as reallock also works for mallock it could also work as free) - but im not sure if really is)

[Anton Shepelev]

fir:

> union rchunk
> {
> chunk c;
> };
>
>
> rchunk AllocChunk(rchunk x, int size)
> {
> x.c.beg = (char*) realloc(x.c.beg, size );
> x.c.end = x.c.beg + size -1;
> return x;
> }
>
>
>
> rchunk dipa;
>
> void rchunk_test()
> {
>
>
> for(int i=1; i<100000; i++)
> {
> dipa = AllocChunk(dipa, i);
> printf("\n %i %p", ChunkLength(dipa.c), dipa.c.beg);
> }
>
> for(int i=100000; i>0; i--)
> {
> dipa = AllocChunk(dipa, i);
> printf("\n %i %p", ChunkLength(dipa.c), dipa.c.beg);
> }
> }

You never use chunk.end .

> it essentially does reallocks on some pointer:
> from 1 uo to 100 000 and then from 100 000 down to
> 1

Basically, you need to employ an allocation-deallo-
cation strategy that will cause maximum memory frag-
mentation -- for I am not sure that your arithmetic
progression is good for that. Then you should cre-
ate your own memory manager or a wrapper around the
standard one that would minimise fragmentation:

https://www.joelonsoftware.com/2001/12/11/back-to-basics/

> is reallocking to zero eqivalent of free?

Yes: https://manned.org/realloc.3 .

--
Anton Shepelev