Author pitrou
Recipients davin, dtasev, gdr@garethrees.org, pitrou, sbt, serhiy.storchaka
Date 2017-07-14.18:24:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500056668.93.0.893298714806.issue30919@psf.upfronthosting.co.za>
In-reply-to
Content
The original changeset in Richard's repository is https://hg.python.org/sandbox/sbt/rev/6c8554a7d068.  Unless Richard answers otherwise, I think it's likely the performance degradation was an oversight.

Given the code we're talking about is POSIX-specific, truncate() (or its sibling os.ftruncate()) is specified to always zero-fill.  So it should be safe to use.

Another related point is that the arena file is created inside get_temp_dir(), which allocates something in /tmp.  On modern Linux systems at least, /tmp is usually backed by persistent storage.  Instead, we could use /run/user/{os.getuid()}, which uses a tmpfs and would therefore save on I/O when later accessing the shared array.
History
Date User Action Args
2017-07-14 18:24:28pitrousetrecipients: + pitrou, sbt, gdr@garethrees.org, serhiy.storchaka, davin, dtasev
2017-07-14 18:24:28pitrousetmessageid: <1500056668.93.0.893298714806.issue30919@psf.upfronthosting.co.za>
2017-07-14 18:24:28pitroulinkissue30919 messages
2017-07-14 18:24:28pitroucreate