On Mon, Sep 2, 2013 at 6:51 AM, Antoine Pitrou
Le Mon, 2 Sep 2013 15:45:22 +0200, Antoine Pitrou
a écrit : Le Mon, 2 Sep 2013 06:18:31 -0700, Eli Bendersky
a écrit : On Mon, Sep 2, 2013 at 1:24 AM, Antoine Pitrou
wrote: Le Sun, 1 Sep 2013 18:02:30 -0700, Eli Bendersky
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