Showing content from http://mail.python.org/pipermail/python-dev/attachments/20170601/2f3e36ea/attachment-0001.html below:
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 06/01/2017 02:03 AM, Victor Stinner
wrote:<br>
</div>
<blockquote
cite="mid:CAMpsgwYGJs=YOVQQAP9-pJ6X4qWeLBo6yoRQyyjKp0e-kpeaBw@mail.gmail.com"
type="cite">
<pre wrap="">2017-06-01 10:41 GMT+02:00 Larry Hastings <a class="moz-txt-link-rfc2396E" href="mailto:larry@hastings.org"><larry@hastings.org></a>:
</pre>
<blockquote type="cite">
<pre wrap="">On 06/01/2017 01:19 AM, Antoine Pitrou wrote:
<blockquote type="cite"><pre wrap="">If you'd like to go that way anyway, I would suggest 1MB as a starting
point in 3.7.</pre></blockquote>
I understand the desire for caution. But I was hoping maybe we could
experiment with 4mb in trunk for a while? We could change it to 1mb--or
even 256k--before beta 1 if we get anxious.
</pre>
</blockquote>
<pre wrap="">
While I fail to explain why in depth, I would prefer to *not* touch
the default arena size at this point.
We need more data, for example measure the memory usage on different
workloads using different arena sizes.</pre>
</blockquote>
<br>
I can't argue with collecting data at this point in the process. My
thesis is simply "the correct value for this tunable parameter in
2001 is probably not the same value in 2017". I don't mind
proceeding *slowly* or gathering more data or what have you for
now. But I would like to see it change somehow between now and
3.7.0b1, because my sense is that we can get some performance for
basically free by updating the value.<br>
<br>
If ARENA_SIZE tracked Moore's Law, meaning that we doubled it every
18 months like clockwork, it'd currently be 2**10 times bigger:
256MB, and we'd be changing it to 512MB at the end of August.<br>
<br>
(And yes, as a high school student I was once bitten by a
radioactive optimizer, so these days when I'm near possible
optimizations my spider-sense--uh, I mean, my
optimization-sense--starts tingling.)<br>
<br>
<blockquote
cite="mid:CAMpsgwYGJs=YOVQQAP9-pJ6X4qWeLBo6yoRQyyjKp0e-kpeaBw@mail.gmail.com"
type="cite">
<pre wrap="">A simple enhancement would be to add an environment variable to change
the arena size at Python startup. Example: PYTHONARENASIZE=1M.</pre>
</blockquote>
<br>
Implementing this would slow down address_in_range which currently
compiles in arena size. It'd be by a tiny amount, but this inline
function gets called very very frequently. It's possible this
wouldn't hurt performance, but my guess is it'd offset the gains we
got from larger arenas, and the net result would be no faster or
slightly slower.<br>
<br>
<br>
<i>/arry</i><br>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4