Efficiency patchlet for pp_aassign()
Ilya Zakharevich writes:
>
> With this patch applied the Tom's program
> use integer;
> @a=map int(rand(30000)), 1..100000;
> @b = sort {$a <=> $b} @a;
>
> Runs in 10.3M (sbrk-en).
Here is another tiny patch to pp_aassign: it preallocates the
array. Memory saving is not very big for the above script (5%), but the
speed advantage may be bigger.
[patch]
> Memory allocation statistics after compilation: (buckets 8..524288)
> 13080 free: 13 109 39 2 13 2 3 2 2 0 0 0 0 0 0 0 0
> 4933288 used: 211 251 519 184 35 6 5 3226 3 0 1 0 0 0 0 0 3
> Total sbrk(): 4960256. Odd ends: sbrk(): 0, malloc(): 1408 bytes.
> Memory allocation statistics after execution: (buckets 8..1048576)
> 529848 free: 13 109 38 1 13 1 1 2 1 1 1 1 1 1 1 1 0 0
> 9782280 used: 211 251 520 185 35 7 7 5914 4 1 2 1 1 1 1 1 4 1
> Total sbrk():
10375168. Odd ends: sbrk(): 0, malloc(): 1408 bytes.
Here is the new data, note the absense of "tails" of growing arrays.
Memory allocation statistics after compilation: (buckets 8..524288)
13080 free: 13 109 39 2 13 2 3 2 2 0 0 0 0 0 0 0 0
4933288 used: 211 251 519 184 35 6 5 3226 3 0 1 0 0 0 0 0 3
Total sbrk(): 4960256. Odd ends: sbrk(): 0, malloc(): 1408 bytes.
Memory allocation statistics after execution: (buckets 8..1048576)
11704 free: 13 109 38 1 13 1 3 1 2 0 0 0 0 0 0 0 0 0
9796616 used: 211 251 520 185 35 7 5 6439 3 0 1 0 0 0 0 0 4 1
Total sbrk(): 9830400. Odd ends: sbrk(): 0, malloc(): 1408 bytes.
> It is 100 bytes per element. Since an integer array takes 24 bytes per
> element here, and there are only 3 arrays around (precalculated
> 1..100000, @a and @b), there is some other leak.
>
> Apparently <=> converts arguments to NV.
No, all this is wrong. It is 20bytes/elt, and we have stack,
mortals-stack, 1..100000, @a and @b.
Everything is OK now, including <=>.
Enjoy,
p5p-msgid: <
199701210305.WAA05451@monk.mps.ohio-state.edu>