One word: profile.

Looking at stat counts alone rather than measuring the total time spent in all types of system calls from strace and profiling is not really useful. ;)

Another thing to keep an eye out for within a startup profile:  how often does the gc collect?  our default gc collection thresholds haven't been tuned in ages afaik [or am i forgetting something] and I know of pathological cases at work where simply doing a gc.disable() before importing a bunch of modules (tons of generated protocol buffer code) and re-enabling it afterwards speeds up this application's startup way more significantly than seems healthy in 2.x... that could be related to the particulars of the protobuf module code though.

-gps

On Sat, Oct 27, 2012 at 4:00 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 28 Oct 2012 01:39:42 +0300
Serhiy Storchaka <storchaka@gmail.com> wrote:

> On 28.10.12 01:06, Brett Cannon wrote:
> > I really doubt that as the amount of stat calls is significantly reduced
> > in Python 3.3 compared to Python 3.2 (startup benchmarks show Python 3.3
> > is roughly 1.66x faster than 3.2 thanks to caching filenames in a
> > directory).
>
> $ strace ./python -c '' 2>&1 | grep -c stat
>
> Python 2.7 - 161 stats
> Python 3.2 - 555 stats
> Python 3.3 - 243 stats

This will probably depend on the length of sys.path:

$ strace -e stat python2.7 -Sc "" 2>&1 | wc -l
35
$ strace -e stat python3.2 -Sc "" 2>&1 | wc -l
298
$ strace -e stat python3.3 -Sc "" 2>&1 | wc -l
106

$ strace -e stat python2.7 -c "" 2>&1 | wc -l
200
$ strace -e stat python3.2 -c "" 2>&1 | wc -l
726
$ strace -e stat python3.3 -c "" 2>&1 | wc -l
180

Regards

Antoine.