[Python-Dev] SEEK_* constants in io and os

[Eli Bendersky]

On Mon, Sep 2, 2013 at 6:51 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Le Mon, 2 Sep 2013 15:45:22 +0200,
> Antoine Pitrou <solipsis at pitrou.net> a écrit :
> > Le Mon, 2 Sep 2013 06:18:31 -0700,
> > Eli Bendersky <eliben at gmail.com> a écrit :
> > > On Mon, Sep 2, 2013 at 1:24 AM, Antoine Pitrou <solipsis at pitrou.net>
> > > wrote:
> > >
> > > > Le Sun, 1 Sep 2013 18:02:30 -0700,
> > > > Eli Bendersky <eliben at gmail.com> a écrit :
> > > > > Hello,
> > > > >
> > > > > I was looking at the possibility of replacing the SEEK_*
> > > > > constants by IntEnums, and the first thing that catches
> > > > > attention is that these constants are defined in both Lib/os.py
> > > > > and Lib/io.py; both places also recently started supporting
> > > > > SEEK_HOLE and SEEK_DATA (though here io refers to os.SEEK_HOLE
> > > > > and os.SEEK_DATA).
> > > >
> > > > What is the runtime cost of doing so? os is a fundamental module
> > > > that is imported by almost every Python program.
> > > >
> > >
> > > Theoretically, it should be very low given that we just need to add
> > > an import and define one class. os already does a number of things
> > > in its toplevel (mostly a few imports which transitively do other
> > > things). Compounded with import caching, since this is done just
> > > once per run, doesn't seem like a problem.
> > >
> > > Empirically, I tried measuring it but I can't discern a difference
> > > with/without translating SEEK_* to enums. There's a fluctuation of
> > > ~1usec which I can't distinguish from noise. Let me know if you have
> > > a good methodology of benchmarking these things
> >
> > How did you get that result? You have to remove to "os" from
> > sys.modules before importing it again, otherwise "import os" will
> > simply return the already imported module.
>
> Oh and remove "enum" too...
>

Yes, now I see a 500 usec difference timed within the Python script. When
timing the whole execution of Python:

$ sudo nice -n -20 perf stat -r 100 python -c 'import os'

It still gets lost in the noise, though. I usually get around 34 ms per run
with 1 - 1.5% jitter. Since 1.5% of 34 ms is ~0.5 ms, it's difficult to
distinguish the runs clearly.

That 0.5 ms seems to be a one-time penalty for the importing of enum (most
time goes to importing, not defining the new class based on IntEnum), no
matter where/how it's used in the stdlib and the user code.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130902/77095dfd/attachment.html>