(original) (raw)
On Sun, Jun 24, 2012 at 3:27 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I don't really want to spread the idea that they're faster, either: the exact same benchmark can probably be made to turn out differently if you have, say, a hundred unzipped eggs on sys.path after the benchmark directory. A more realistic benchmark would import more than one module, though... and then it goes back and forth, dueling benchmarks that can always be argued against with a different benchmark measuring different things with other setup conditions.
That's what I meant by "lost in the noise": the outcome of the benchmark depends on which of many potentially-plausible setups and applications you choose to use as your basis for measurement, so it's silly to think that either omitting or including \_\_init\_\_.py should be done for performance reasons. Do whatever your application needs, because it's not going to make much difference either way in any realistic program.
>> In short, it's not worth worrying about, and definitely nothing thatPJE wants people to spread an idea, not to avoid them doing so.
>> should cause people to spread an idea that \_\_init\_\_.py somehow speeds
>> things up.
>
> The best way to avoid people spreading that idea would be to show hard
> measurements.
In any case, hard measurements might help to spread the idea, here are
mine. For the attached project, ec656d79b8ac gives, on my system
import time for a namespace package: 113盜 (fastest run, hot caches)
import time for a regular package: 128盜 (---- " ------)
first-time import of regular package: 1859盜 (due to pyc generation)
(remove \_\_init\_\_.py and \_\_pycache\_\_ to construct the first setup)
So namespace packages are indeed faster than regular packages, at least
in some cases.
I don't really want to spread the idea that they're faster, either: the exact same benchmark can probably be made to turn out differently if you have, say, a hundred unzipped eggs on sys.path after the benchmark directory. A more realistic benchmark would import more than one module, though... and then it goes back and forth, dueling benchmarks that can always be argued against with a different benchmark measuring different things with other setup conditions.
That's what I meant by "lost in the noise": the outcome of the benchmark depends on which of many potentially-plausible setups and applications you choose to use as your basis for measurement, so it's silly to think that either omitting or including \_\_init\_\_.py should be done for performance reasons. Do whatever your application needs, because it's not going to make much difference either way in any realistic program.