<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2019 at 5:15 PM Steve Dower <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23May2019 0542, Inada Naoki wrote:<br>
> 1. perf shows 95% of CPU time is eaten by _PyObject_Free, not kernel space.<br>
> 2. This loop is cleary hot:<br>
> <a href="https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L1816-L1819" rel="noreferrer" target="_blank">https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L1816-L1819</a><br>
> <br>
> I can attach the process by gdb and I confirmed many arenas have<br>
> same nfreepools.<br>
<br>
It's relatively easy to test replacing our custom allocators with the <br>
system ones, yes? Can we try those to see whether they have the same <br>
characteristic?<br>
<br>
Given the relative amount of investment over the last 19 years [1], I <br>
wouldn't be surprised if most system ones are at least as good for our <br>
needs now. Certainly Windows HeapAlloc has had serious improvements in <br>
that time to help with fragmentation and small allocations.<br></blockquote><div><br></div><div>FYI, and I've mentioned this at PyCon to a few people (might've been you, Steve, I don't remember) -- but at Google we've experimented with disabling obmalloc when using TCMalloc (a faster and thread-aware malloc, which makes a huge difference within Google when dealing with multi-threaded C++ libraries), both using the usual Python benchmarks and real-world code with real-world workloads (a core part of YouTube, for example), all on Linux. There's still a significant benefit to using obmalloc when using glibc's malloc, and also a noticeable benefit when using TCMalloc. There are certainly cases where it doesn't matter much, and there may even be cases where the overhead of obmalloc isn't worth it, but I do believe it's still a firm net benefit.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Steve<br>
<br>
[1]: <br>
<a href="https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L769" rel="noreferrer" target="_blank">https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L769</a><br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/thomas%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/thomas%40python.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>><br><br>Hi! I'm an email virus! Think twice before sending your email to help me spread!</div></div>