[PATCH v3 0/5] malloc: tcache improvements

[Cupertino Miranda]

Hi Wilco,

I have worked on improving performance of the patch series.
After collecting results with bench-malloc-simple and 
bench-malloc-thread, I found the execution times were too close and 
oscillating to really provide a good reference for performance measurement.

I took the initiative to run mimalloc-bench with the following code 
(patch partitioning):
  - master as the baseline,
  - v3 (patches 1 to 3),
  - v3 (all 5 patches),
  - inline (with __always_inline in tcache_free),
  - v4 (my recent changes to improve performance: added fast_csize2tidx, 
trim spurious conditions and adding __glibc_(un)likely to conditions).
All results were taken without any tunables set, i.e. the tcache is 
still limited to roughly 1k chunks and bigger chunks caching is not 
benchmarked.

For reference I will attach both a PNG chart and the spreadsheet where I 
collected both execution time and max RSS's for individual benchmark 
executions. I only plotted performance, as there are no changes in the 
patches to justify caring for RSS, considering no tunable is used.

I will soon prepare the patches and submit has a new v4 series.
For v4 I will leave the new code in isolated patches to easily follow 
the recent changes.

Hope you see the value of running mimalloc-bench and accept it as a 
valid benchmark for the purpose.

Cheers,
Cupertino


On 06-03-2025 17:01, Wilco Dijkstra wrote:
> Hi Cupertino,
> 
>> I have just realized that in my code basis _int_free function did not
>> get inline for some reason. Do not know the reason yet.
> 
> It's because _int_free() and _int_free_check() must be inlined for performance
> but aren't correctly marked as __always_inline. I think that is a bug due to the
> recent cleanups.
> 
>> Performance numbers on bench-malloc-thread-32 improved significantly
>> once I set _int_free to __always_inline.
> 
> Indeed, bench-malloc-simple looks far better with that (2.4% average slowdown),
> though bench-malloc-thread still shows a fairly large 22-23% loss. Perf results
> suggest the slowdown is mainly due to malloc() since its sample count increases
> by almost 50%! I don't see a function that isn't inlined, but it's likely something
> obvious here too.
> 
> Cheers,
> Wilco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chart.png
Type: image/png
Size: 48292 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250314/40a307ab/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: results.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 73422 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250314/40a307ab/attachment-0001.ods>