On Mon, Sep 2, 2013 at 6:51 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> Le Mon, 2 Sep 2013 15:45:22 +0200, > Antoine Pitrou <solip...@pitrou.net> a écrit : > > Le Mon, 2 Sep 2013 06:18:31 -0700, > > Eli Bendersky <eli...@gmail.com> a écrit : > > > On Mon, Sep 2, 2013 at 1:24 AM, Antoine Pitrou <solip...@pitrou.net> > > > wrote: > > > > > > > Le Sun, 1 Sep 2013 18:02:30 -0700, > > > > Eli Bendersky <eli...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com